Also further improve the documentation and testing around --root.
Previously the root=setting in the CFG file was treated identically
to passing --root=setting on the command line, which seems undesirable
since it depends on were cpplint.cfg was invoked from (for relative
paths).
Judging on settings such as 'exclude_files' it seems within the spirit
to make the settings 'current working directory' contextual to the
same directory that CPPLINT.cfg is in.
This also makes execution consistent (picking up the "correct" settings)
regardless of the CWD when executing cpplint.py.
Example:
echo 'root=..' >> /a/b/c/CPPLINT.cfg
cd /
cpplint.py /a/b/c/source_file.h
# expects header guard of C_SOURCE_FILE_H_
However the old behavior would use '/../' = '/'
and incorrectly think the root was 'A_B_C_SOURCE_FILE_H_'.
Using cpplint.py --root with directories at a more outer level
will now prepend the header guard with all the directories from the
root to the file.
For example given
ls /a/b/c # /a/b/c/.git /a/b/c/filename.h
cpplint.py --root=/a/b /a/b/c/filename.h # C_FILENAME_H_
# no root behavior:
cpplint.py /a/b/c/filename.h # FILENAME_H_
Also supports relative paths:
cd /a/b/c
cpplint.py --root=.. filename.h # C_FILENAME_H_
Note that the old usage is still supported:
cd /a/b/c
mkdir -p d/e/f
touch /a/b/c/d/e/f/filename.h
cpplint.py --root=d/e/f d/e/f/filename.h # FILENAME_H_
which would "strip" the prefix rather than prepend an extra prefix.
(Invalid root prefixes are as before also ignored)
Using cpplint.py --root with directories at a more outer level
than the repository would not work.
For example given
/a/b/c/.git/filename.cpp
Trying to use --root=/a/b would get ignored, and it would
ask for a headerguard of FILENAME_H_ instead of C_FILENAME_H_
as expected.
Now --root will always use the "full name" and then strip off --root
prefix, giving us the desired effect.
There are links out in the wild to the old XML style guide. An XML file that links to the new style guide location ensures that those links are not completely broken.
Before C++11, we were using a hack to disable copy constructors or copy
assignment by declaring the methods private and not implementing them.
This hack required the respective macros to be placed in the private:
declarations of a class.
The macros have switched to use the C++11 "= delete" syntax some time
ago in both v8 and chromium:
https://codereview.chromium.org/1123723003/https://codereview.chromium.org/2017213002
Also the comments are now updated, since the macros do not need to be
in the private: declarations any more:
https://chromium-review.googlesource.com/c/577687https://chromium-review.googlesource.com/c/578027
This change also removes the presubmit check that checked that the
macros are only used in the private declarations.
* Added Go while I was in there. (@rakyll or @adg might have feedback on the link I used)
* Rewrote things a bit to make the new links fit.
* Copy edited a bit because I couldn't help myself.
If a constructor is marked constexpr it evades the explicit constructor
check right now, since the check only knows about the inline keyword.
Teach it that constexpr can be used also.
