1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-22 02:33:06 +01:00

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
This commit is contained in:
Aaron Ballman 2018-08-10 17:26:07 +00:00
parent 1a2f6a6f75
commit bf8501e8ad
3 changed files with 16 additions and 3 deletions

View File

@ -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
^^^^^^^^^^^^^^^^^^^^^^^^

View File

@ -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

View File

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