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

Author: AaronBallman

llvm/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
 ^^^^^^^^^^^^^^^^^^^^^^^^
 

llvm/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 <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

llvm/docs/Lexicon.rst

@@ -185,6 +185,7 @@ M
 
 N
 -
+.. _nfc:
 
 **NFC**
   "No functional change". Used in a commit message to indicate that a patch