…ationFileExtensions
Deprecated since clang-tidy 17. Use the corresponding global options
instead.
Fixes#61947
---------
Co-authored-by: Carlos Gálvez <carlos.galvez@zenseact.com>
Re-introduce the patch that was reverted previously.
In the first attempt, the checks would not be able to
read from the global option, since getLocalOrGlobal
only works with string types. Additional logic is needed
in order to support both use cases in the transition
period. All that logic will be removed when the local
options are fully removed.
We have a number of checks designed to analyze problems
in header files only, for example:
bugprone-suspicious-include
google-build-namespaces
llvm-header-guard
misc-definitions-in-header
...
All these checks duplicate the same logic and options
to determine whether a location is placed in the main
source file or in the header. More checks are coming
up with similar requirements.
Thus, to remove duplication, let's move this option
to the top-level configuration of clang-tidy (since
it's something all checks should share).
Add a deprecation notice for all checks that use the
local option, prompting to update to the global option.
Differential Revision: https://reviews.llvm.org/D142655
We forgot to apply the change to headers in the previous patch,
due to missing "-header-filter" in the run-clang-tidy invocation.
Differential Revision: https://reviews.llvm.org/D142307
Fixes https://bugs.llvm.org/show_bug.cgi?id=48613.
llvm-header-guard is suggesting header guards with leading underscores
if the header file path begins with a '/' or similar special character.
Only reserved identifiers should begin with an underscore.
Differential Revision: https://reviews.llvm.org/D114149
Just adds the storeOptions for Checks that weren't already storing their options.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D82223
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
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
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
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
The patch was generated using this command:
$ clang-tidy/tool/run-clang-tidy.py -header-filter=.*clang-tidy.* -fix \
-checks=-*,llvm-header-guard clang-tidy.*
$ svn revert --recursive clangt-tidy/llvm/
(to revert a few buggy fixes)
llvm-svn: 231669
Summary:
This patch makes the check work better for LLVM code:
* always fix existing #endif comments
* use one space before the comment (+allow customization for other styles)
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5795
llvm-svn: 219789
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
