The Yaml module is missing on some systems and on many of clang buildbots.
But the test for run-clang-tidy.py doesn't fail due to 'NOT' statement masking a python runtime error.
This patch conditionally imports and enables the yaml module only if it's present in the system.
If not, then '-export-fixes' is disabled.
Differential Revision: https://reviews.llvm.org/D59734
llvm-svn: 357114
Summary:
Add a way to expand modular headers for PPCallbacks. Checks can opt-in for this
expansion by overriding the new registerPPCallbacks virtual method and
registering their PPCallbacks in the preprocessor created for this specific
purpose.
Use module expansion in the readability-identifier-naming check
Reviewers: gribozavr, usaxena95, sammccall
Reviewed By: gribozavr
Subscribers: nemanjai, mgorny, xazax.hun, kbarton, jdoerfert, cfe-commits
Tags: #clang, #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D59528
llvm-svn: 356750
[clang-tidy] Parallelize clang-tidy-diff.py
This patch has 2 rationales:
- large patches lead to long command lines and often cause max command line length restrictions imposed by OS;
- clang-tidy runs on modified files are independent and can be done in parallel, the same as done for run-clang-tidy.
Differential Revision: https://reviews.llvm.org/D5766
llvm-svn: 356649
[clang-tidy] Parallelize clang-tidy-diff.py
This patch has 2 rationales:
- large patches lead to long command lines and often cause max command line length restrictions imposed by OS;
- clang-tidy runs on modified files are independent and can be done in parallel, the same as done for run-clang-tidy.
Differential Revision: https://reviews.llvm.org/D57662
llvm-svn: 356565
This patch has 2 rationales:
- large patches lead to long command lines and often cause max command line length restrictions imposed by OS;
- clang-tidy runs on modified files are independent and can be done in parallel, the same as done for run-clang-tidy.
Differential Revision: https://reviews.llvm.org/D57662
llvm-svn: 356547
Summary:
The current install-clang-headers target installs clang's resource
directory headers. This is different from the install-llvm-headers
target, which installs LLVM's API headers. We want to introduce the
corresponding target to clang, and the natural name for that new target
would be install-clang-headers. Rename the existing target to
install-clang-resource-headers to free up the install-clang-headers name
for the new target, following the discussion on cfe-dev [1].
I didn't find any bots on zorg referencing install-clang-headers. I'll
send out another PSA to cfe-dev to accompany this rename.
[1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html
Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille
Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits
Tags: #clang, #sanitizers, #lldb, #openmp, #llvm
Differential Revision: https://reviews.llvm.org/D58791
llvm-svn: 355340
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
It's included in a new header ClangTidyForceLinker.h and should not
be included the second time.
Follow up for the https://reviews.llvm.org/D55595
llvm-svn: 349132
Extract code that forces linking to the separate header and include it in both plugin and standalone tool.
Try 2: missing header guard and "clang/Config/config.h" are added to the new header.
Differential Revision: https://reviews.llvm.org/D55595
llvm-svn: 349131
Extract code that forces linking to the separate header and include it in both plugin and standalone tool
Differential Revision: https://reviews.llvm.org/D55595
llvm-svn: 349038
Summary:
Currently ClangTidyContext::diag() sends the diagnostics to a
DiagnosticsEngine, which probably delegates to a ClangTidyDiagnosticsConsumer,
which is supposed to go back and populate ClangTidyContext::Errors.
After this patch, the diagnostics are stored in the ClangTidyDiagnosticsConsumer
itself and can be retrieved from there.
Why?
- the round-trip from context -> engine -> consumer -> context is confusing
and makes it harder to establish layering between these things.
- context does too many things, and makes it hard to use clang-tidy as a library
- everyone who actually wants the diagnostics has access to the ClangTidyDiagnosticsConsumer
The most natural implementation (ClangTidyDiagnosticsConsumer::take()
finalizes diagnostics) causes a test failure: clang-tidy-run-with-database.cpp
asserts that clang-tidy exits successfully when trying to process a file
that doesn't exist.
In clang-tidy today, this happens because finish() is never called, so the
diagnostic is never flushed. This looks like a bug to me.
For now, this patch carefully preserves that behavior, but I'll ping the
authors to see whether it's deliberate and worth preserving.
Reviewers: hokein
Subscribers: xazax.hun, cfe-commits, alexfh
Differential Revision: https://reviews.llvm.org/D53953
llvm-svn: 345961
Conditionally compile the parts of clang-tidy which depend on the static
analyzer.
Funnily enough, I made the patch to exclude this from the build in 2013,
and it was committed with the comment that the tool should not be fully
excluded, but only the parts of it which depend on the analyzer should
be excluded.
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20130617/081797.html
This commit implements that idea.
Reviewed By: aaron.ballman
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D52334
llvm-svn: 343528
Summary:
Continuation of D46504.
Example output:
```
$ clang-tidy -enable-check-profile -store-check-profile=. -checks=-*,readability-function-size source.cpp
$ # Note that there won't be timings table printed to the console.
$ cat *.json
{
"file": "/path/to/source.cpp",
"timestamp": "2018-05-16 16:13:18.717446360",
"profile": {
"time.clang-tidy.readability-function-size.wall": 1.0421266555786133e+00,
"time.clang-tidy.readability-function-size.user": 9.2088400000005421e-01,
"time.clang-tidy.readability-function-size.sys": 1.2418899999999974e-01
}
}
```
There are two arguments that control profile storage:
* `-store-check-profile=<prefix>`
By default reports are printed in tabulated format to stderr. When this option
is passed, these per-TU profiles are instead stored as JSON.
If the prefix is not an absolute path, it is considered to be relative to the
directory from where you have run :program:`clang-tidy`. All `.` and `..`
patterns in the path are collapsed, and symlinks are resolved.
Example:
Let's suppose you have a source file named `example.cpp`, located in
`/source` directory.
* If you specify `-store-check-profile=/tmp`, then the profile will be saved
to `/tmp/<timestamp>-example.cpp.json`
* If you run :program:`clang-tidy` from within `/foo` directory, and specify
`-store-check-profile=.`, then the profile will still be saved to
`/foo/<timestamp>-example.cpp.json`
Reviewers: alexfh, sbenza, george.karpenkov, NoQ, aaron.ballman
Reviewed By: alexfh, george.karpenkov, aaron.ballman
Subscribers: Quuxplusone, JonasToth, aaron.ballman, llvm-commits, rja, Eugene.Zelenko, xazax.hun, mgrang, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D46602
llvm-svn: 334101
Summary: The alpha checkers can already be enabled using the clang driver, this allows them to be enabled using the clang-tidy as well. This can make it easier to test the alpha checkers with projects which already support the compile_commands.json. It will also allow more people to give feedback and patches about the alpha checkers since they can run it as part of clang tidy checks.
Reviewers: aaron.ballman, hokein, ilya-biryukov, alexfh, lebedev.ri, xbolva00
Reviewed By: aaron.ballman, alexfh, lebedev.ri, xbolva00
Subscribers: xbolva00, NoQ, dcoughlin, lebedev.ri, xazax.hun, cfe-commits
Patch by Paul Fultz II!
Differential Revision: https://reviews.llvm.org/D46159
llvm-svn: 332609
Summary:
As discussed in D45931, currently, profiling output of clang-tidy is somewhat not great.
It outputs one profile at the end of the execution, and that profile contains the data
from the last TU that was processed. So if the tool run on multiple TU's, the data is
not accumulated, it is simply discarded.
It would be nice to improve this.
This differential is the first step - make this profiling info per-TU,
and output it after the tool has finished processing each TU.
In particular, when `ClangTidyASTConsumer` destructor runs.
Next step will be to add a CSV (JSON?) printer to store said profiles under user-specified directory prefix.
Reviewers: alexfh, sbenza
Reviewed By: alexfh
Subscribers: Eugene.Zelenko, mgorny, xazax.hun, mgrang, klimek, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D46504
llvm-svn: 331763
Remove the `AnalyzeTemporaryDtors` option, since the corresponding
`cfg-temporary-dtors` option of the Static Analyzer defaults to `true` since
r326461.
llvm-svn: 331456
When no inputs given, the tools should not only produce the help message, but
also return a non-zero exit code. Fixed tests accordingly.
llvm-svn: 328199
Exit with a non-zero value in case any of the underlying clang-tidy
invocations exit with a non-zero value.
This is useful in case WarningsAsErrors is enabled for some of the
checks: if any of those checks find something, the exit status now
reflects that.
Also add the ability to use run-clang-tidy.py via lit, and assert that
the exit code is not 0 when modernize-use-auto is triggered
intentionally.
Reviewers: alexfh, aaron.ballman
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D44366
llvm-svn: 327854
Adding a Zircon module to clang-tidy for checks specific to the Zircon
kernel, and adding a checker to fuchsia-zx (for zircon) to flag instances
where specific objects are temporarily created.
Differential Revision: https://reviews.llvm.org/D44346
llvm-svn: 327590
Updating the run-clang-tidy.py script to allow specification of the
config argument to the clang-tidy invocation.
Differential Revision: https://reviews.llvm.org/D43538
llvm-svn: 327186
Summary:
It allows to remap and override files and directories on disk when
running clang-tidy. The intended use case for the flag is running
standalone clang-tidy binary for IDE and editor integration.
Patch by Vladimir Plyashkun.
Reviewers: alexfh, benlangmuir, ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: ilya-biryukov, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D41535
llvm-svn: 323196
We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
Dependencies added in this way apply to both the target and its
dependencies, i.e. they become part of the executable's link interface
and are transitive.
Transitive dependencies generally don't make sense for executables,
since you wouldn't normally be linking against an executable. This also
causes issues for generating install export files when using
LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM
library dependencies, which are currently added as interface
dependencies. If clang is in the distribution components but the LLVM
libraries it depends on aren't (which is a perfectly legitimate use case
if the LLVM libraries are being built static and there are therefore no
run-time dependencies on them), CMake will complain about the LLVM
libraries not being in export set when attempting to generate the
install export file for clang. This is reasonable behavior on CMake's
part, and the right thing is for LLVM's build system to explicitly use
PRIVATE dependencies for executables.
Unfortunately, CMake doesn't allow you to mix and match the keyword and
non-keyword target_link_libraries signatures for a single target; i.e.,
if a single call to target_link_libraries for a particular target uses
one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must
also be updated to use those keywords. This means we must do this change
in a single shot. I also fully expect to have missed some instances; I
tested by enabling all the projects in the monorepo (except dragonegg),
and configuring both with and without shared libraries, on both Darwin
and Linux, but I'm planning to rely on the buildbots for other
configurations (since it should be pretty easy to fix those).
Even after this change, we still have a lot of target_link_libraries
calls that don't specify a scope keyword, mostly for shared libraries.
I'm thinking about addressing those in a follow-up, but that's a
separate change IMO.
Differential Revision: https://reviews.llvm.org/D40823
llvm-svn: 319840
Unfortunately, these python scripts are not tested currently. I did the testing
manually on LLVM by editing the CMake generated compilation database to
contain relative paths for some of the files.
Differential Revision: https://reviews.llvm.org/D39603
llvm-svn: 317468
An installation rule for the executable with the correct component is
already created by `add_clang_tool`, so the rule in this file is
redundant. Correct the installation component for the Python scripts so
that they also get installed by `install-clang-tidy`.
llvm-svn: 317155
Summary:
This is part 1 of 3 of a series of changes to improve Objective-C
linting in clang-tidy.
This introduces a new clang-tidy module, `objc`, specifically for
Objective-C / Objective-C++ checks.
The module is currently empty; D39142 adds the first check.
Test Plan: `ninja check-clang-tools`
Patch by Ben Hamilton!
Reviewers: hokein, alexfh
Reviewed By: hokein
Subscribers: Wizard, mgorny
Differential Revision: https://reviews.llvm.org/D39188
llvm-svn: 316643
To get MS-style inline assembly, we need to link in the various
backends. Some other clang tools already do this, and this issue
has been raised with clang-tidy several times, indicating there
is sufficient desire to make this work.
Differential Revision: https://reviews.llvm.org/D38549
llvm-svn: 316246
This patch adds the option to keep the list of proposed fixes even though they
should not be applied.
This allows to detect possible fixes using the parallelised run-clang-tidy.py
and apply them using clang-apply-replacements at a later time.
Essentially the patch causes the individual temporary yaml files by the parallel
clang-tidy instances to be merged into one user-defined file.
Patch by Michael F. Herbst!
Differential revision: https://reviews.llvm.org/D31326
llvm-svn: 308726
Created new module bugprone and placed the check in that.
Finds memset() calls with potential mistakes in their arguments.
Replaces and extends the existing google-runtime-memset-zero-length check.
Cases covered:
* Fill value is a character '0'. Integer 0 might have been intended.
* Fill value is out of char range and gets truncated.
* Byte count is zero. Potentially swapped with the fill value argument.
Patch by: Reka Nikolett Kovacs
Differential Revision: https://reviews.llvm.org/D32700
llvm-svn: 308020
Summary:
A common source of security bugs is code that opens a file descriptors without using the O_CLOEXEC flag. (Without that flag, an opened sensitive file would remain open across a fork+exec to a lower-privileged SELinux domain, leaking that sensitive data.).
Add a new Android module and one checks in clang-tidy.
-- open(), openat(), and open64() should include O_CLOEXEC in their flags argument. [android-file-open-flag]
Links to part2 and part3:
https://reviews.llvm.org/D33745https://reviews.llvm.org/D33747
Reviewers: chh, alexfh, aaron.ballman, hokein
Reviewed By: alexfh, hokein
Subscribers: jbcoe, joerg, malcolm.parsons, Eugene.Zelenko, srhines, mgorny, xazax.hun, cfe-commits, krytarowski
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D33304
llvm-svn: 306165
Zinovy Nis