Changed the extension check to include the option of ",h,hh,hpp,hxx" instead of just returning whether the file ended with ".h".
Differential revision: https://reviews.llvm.org/D20512
llvm-svn: 279803
The include order check would get notified of all include
directives in a depth-first manner. This created the
possibility of an include directive from a header file
interfering with the sort order of a set of two distinct
blocks from the top level cpp file, if that include directive
was on just the right line.
With this patch we bucket the include directives by the file
in which they appear in and process one bucket at a time,
so that directives from different files do not get mixed
together into the same list.
Reviewed By: alexfh
Differential Revision: https://reviews.llvm.org/D23434
llvm-svn: 278546
Summary: This is a fix for the new ExprWithCleanups introduced by clang's temporary variable lifetime marks change.
Reviewers: bkramer, sbenza, angelgarcia, alexth
Subscribers: rsmith, cfe-commits
Differential Revision: http://reviews.llvm.org/D21243
llvm-svn: 273310
Summary:
This is a step forward cleaning up the namespaces in clang-tidy/utils.
There is no behavior change.
Reviewers: alexfh
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D19819
llvm-svn: 268356
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"Now I am become Death, the destroyer of worlds."
-J. Robert Oppenheimer
Reviewers: chandlerc, grosbach, bob.wilson, echristo
Subscribers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D16475
llvm-svn: 258864
IncludeDirectives struct used a StringRef that pointed to a stack variable
(SmallString<128> FilenameBuffer from PPDirectives.cpp:1513).
http://reviews.llvm.org/D12632
Patch by Marek Kurdej!
llvm-svn: 246856
Changes mostly address formatting and unification of the style. Use
MarkDown style for inline code snippets and lists. Added some text
for a few checks.
The idea is to move most of the documentation out to separate rST files and have
implementation files refer to the corresponding documentation files.
llvm-svn: 246169
clang-tidy checks are organized into modules. This refactoring moves the llvm
module checks to clang::tidy::llvm
http://reviews.llvm.org/D7995
Patch by Richard Thomson!
llvm-svn: 230952
Summary:
Register readability checks in a separate module. Renamed the checks
and test file names accordingly.
Reviewers: djasper, klimek
Reviewed By: klimek
Subscribers: curdeius, cfe-commits
Differential Revision: http://reviews.llvm.org/D5936
llvm-svn: 220631
Summary:
This uses a bit hacky way to set the defaults for the spaces before
comments, but it's also one of the simplest ways. Fixed a bug with how the
SpacesBeforeComments option was used.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5410
llvm-svn: 218240
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
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
There are still a couple of rough edges in here but it is working fine
on LLVM and generates the same results as sort_includes.py if there are
no blank lines involved.
Differential Revision: http://reviews.llvm.org/D4741
llvm-svn: 215152
- Remove unused includes.
- Minor wording fix.
- Added support to check for clang-tidy messages to check_clang_tidy_fix.sh
= Updated test case.
llvm-svn: 212540
Those often cause use after free bugs and should be generally avoided.
Technically it is safe to have a Twine with >=2 components in a variable
but I don't think it is a good pattern to follow. The almost trivial checker
comes with elaborated fix-it hints that turn the Twine into a std::string
if necessary and otherwise fall back to the original type if the Twine
is created from a single value.
llvm-svn: 212535
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
Summary:
Pass check names all the way from ClangTidyModule through
ClangTidyCheck and ClangTidyContext to ClangTidyError, and output it in
handleErrors. This allows to find mis-behaving check and disable it easily.
Reviewers: djasper, klimek
Reviewed By: djasper
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2534
llvm-svn: 199094
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
Piotr Padlewski