| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Each check can implement readOptions and storeOptions methods to read
and store custom options. Each check's options are stored in a local namespace
to avoid name collisions and provide some sort of context to the user.
Reviewers: bkramer, klimek
Reviewed By: klimek
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5296
llvm-svn: 217661
|
|
|
|
|
|
|
|
| |
newlines involved.
Getting that right is just not worth it.
llvm-svn: 217480
|
|
|
|
|
|
|
|
|
| |
we can also fix the original header guard.
We still allow an _ at the end of a header guard since it's so common, but
remove it now when the #endif comment is changed.
llvm-svn: 216462
|
|
|
|
|
|
| |
Turning block comments into line comments just creates unecessary churn.
llvm-svn: 216072
|
|
|
|
|
| |
FIXME: It seems this might be incompatible to dos path. Investigating.
llvm-svn: 215590
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The implementation is split into a generic part and a LLVM-specific part.
Other codebases can implement it with their own style. The specific features
supported are:
- Verification (and fixing) of header guards against a style based on the file path
- Automatic insertion of header guards for headers that are missing them
- A warning when the header guard doesn't enable our fancy header guard optimization
(e.g. when there's an include preceeding the guard)
- Automatic insertion of a comment with the guard name after #endif.
For the LLVM style we disable #endif comments for now, they're not very common
in the codebase. We also only flag headers in the include directories, there
doesn't seem to be a common style outside.
Differential Revision: http://reviews.llvm.org/D4867
llvm-svn: 215548
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Handle various forms of existing namespace closing comments, fix
existing comments with wrong namespace name, ignore short namespaces.
The state of this check now seems to be enough to enable it by default to gather
user feedback ;)
Reviewers: klimek
Reviewed By: klimek
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3825
llvm-svn: 209141
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: klimek
Reviewed By: klimek
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2895
llvm-svn: 202399
|
|
|
|
|
|
|
|
|
|
| |
always produce as pretty of results as it does in LLVM and Clang, but
I don't mind and the value of having a single canonical ordering is very
high IMO.
Let me know if you spot really serious problems here.
llvm-svn: 198703
|
|
This is the first version of a possible clang-tidy architecture. The
purpose of clang-tidy is to detect errors in adhering to common coding
patterns, e.g. described in the LLVM Coding Standards.
This is still heavily in flux.
Review: http://llvm-reviews.chandlerc.com/D884
llvm-svn: 187345
|