From bf8501e8ad945af13663d1f05fb3f0ea6423e807 Mon Sep 17 00:00:00 2001 From: Aaron Ballman Date: Fri, 10 Aug 2018 17:26:07 +0000 Subject: [PATCH] Update the coding standards and developer policy documentation surrounding whitespace. Clarify that you should not introduce trailing whitespace when making a commit and that you should not remove trailing whitespace that's unrelated to code you are changing or are about to change. Then clarified the developer policy around what is considered an obvious whitespace commit. llvm-svn: 339455 --- docs/CodingStandards.rst | 10 ++++++++-- docs/DeveloperPolicy.rst | 8 +++++++- docs/Lexicon.rst | 1 + 3 files changed, 16 insertions(+), 3 deletions(-) diff --git a/docs/CodingStandards.rst b/docs/CodingStandards.rst index feb3bf0eb03..6ed7a95c9f0 100644 --- a/docs/CodingStandards.rst +++ b/docs/CodingStandards.rst @@ -494,8 +494,8 @@ for it (vs something else, like 90 columns). This is one of many contentious issues in coding standards, but it is not up for debate. -Use Spaces Instead of Tabs -^^^^^^^^^^^^^^^^^^^^^^^^^^ +Whitespace +^^^^^^^^^^ In all cases, prefer spaces to tabs in source files. People have different preferred indentation levels, and different styles of indentation that they @@ -509,6 +509,12 @@ indentation, **DO NOT** do that in the middle of a chunk of code with two spaces of indentation. Also, do not reindent a whole source file: it makes for incredible diffs that are absolutely worthless. +Do not commit changes that include trailing whitespace. If you find trailing +whitespace in a file, do not remove it unless you're otherwise changing that +line of code. Some common editors will automatically remove trailing whitespace +when saving a file which causes unrelated changes to appear in diffs and +commits. + Indent Code Consistently ^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/docs/DeveloperPolicy.rst b/docs/DeveloperPolicy.rst index 9bd50f142b9..efc9853f3c5 100644 --- a/docs/DeveloperPolicy.rst +++ b/docs/DeveloperPolicy.rst @@ -376,7 +376,13 @@ If you have recently been granted commit access, these policies apply: obvious. This is clearly a subjective decision --- we simply expect you to use good judgement. Examples include: fixing build breakage, reverting obviously broken patches, documentation/comment changes, any other minor - changes. + changes. Avoid committing formatting- or whitespace-only changes outside of + code you plan to make subsequent changes to. Also, try to separate + formatting or whitespace changes from functional changes, either by + correcting the format first (ideally) or afterward. Such changes should be + highly localized and the commit message should clearly state that the commit + is not intended to change functionality, usually by stating it is + :ref:`NFC `. #. You are allowed to commit patches without approval to those portions of LLVM that you have contributed or maintain (i.e., have been assigned diff --git a/docs/Lexicon.rst b/docs/Lexicon.rst index 981aaea961a..e1f374281f4 100644 --- a/docs/Lexicon.rst +++ b/docs/Lexicon.rst @@ -185,6 +185,7 @@ M N - +.. _nfc: **NFC** "No functional change". Used in a commit message to indicate that a patch