…dy.py
Currently, run_clang_tidy.py does not correctly display the list of
checks picked up from the top-level .clang-tidy file. The reason for
that is that we are passing an empty string as input file.
However, that's not how we are supposed to use clang-tidy to list
checks. Per
65eccb463d,
we simply should not pass any file at all - the internal code of
clang-tidy will pass a "dummy" file if that's the case and get the
.clang-tidy file from the current working directory.
Fixes#136659
Co-authored-by: Carlos Gálvez <carlos.galvez@zenseact.com>
A change list may include files that are not part of the compile
database, which can cause clang-tidy to fail (e.g., due to missing
included headers). To prevent false negatives, we should allow to skip
processing these files.
If a add_clang_library call doesn't specify building as static or shared
library they are implicitly added to the list static libraries that is
linked in to clang-cpp shared library here.
315ba77406/clang/cmake/modules/AddClang.cmake (L107)
Because the clang-tools-extra libraries targets were declared after
clang-cpp they by luck never got linked to clang-cpp.
This change is required for clang symbol visibility macros on windows to
work correctly for clang tools since we need to distinguish if a target
being built will be importing or exporting clang symbols from the
clang-cpp DLL.
On my new machine, the script outputs some shutdown noise:
```
Ctrl-C detected, goodbye.
Traceback (most recent call last):
File "/home/nvankempen/llvm-project/./clang-tools-extra/clang-tidy/tool/run-clang-tidy.py", line 626, in <module>
asyncio.run(main())
File "/usr/lib/python3.10/asyncio/runners.py", line 44, in run
return loop.run_until_complete(main)
File "/usr/lib/python3.10/asyncio/base_events.py", line 636, in run_until_complete
self.run_forever()
File "/usr/lib/python3.10/asyncio/base_events.py", line 603, in run_forever
self._run_once()
File "/usr/lib/python3.10/asyncio/base_events.py", line 1871, in _run_once
event_list = self._selector.select(timeout)
File "/usr/lib/python3.10/selectors.py", line 469, in select
fd_event_list = self._selector.poll(timeout, max_ev)
KeyboardInterrupt
```
This fixes it. Also remove an unused typing import.
Relevant documentation:
https://docs.python.org/3/library/asyncio-runner.html#handling-keyboard-interruption
There is no need to support Python 2.7 anymore, Python 3.3+ has
`subprocess.DEVNULL`. This is good practice and also prevents file
handles from
staying open unnecessarily.
Also remove a couple unused or unneeded `__future__` imports.
Fix the builds with LLVM_TOOL_LLVM_DRIVER_BUILD enabled.
LLVM_ENABLE_EXPORTED_SYMBOLS_IN_EXECUTABLES is not completely
compatible with export_executable_symbols as the later will be ignored
if the previous is set to NO.
Fix the issue by passing if symbols need to be exported to
llvm_add_exectuable so the link flag can be determined directly
without calling export_executable_symbols_* later.
`LLVM_ENABLE_EXPORTED_SYMBOLS_IN_EXECUTABLES` is not completely
compatible with `export_executable_symbols` as the later will be ignored
if the previous is set to NO.
Fix the issue by passing if symbols need to be exported to
`llvm_add_exectuable` so the link flag can be determined directly
without calling `export_executable_symbols_*` later.
[There is
work](https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-python-version/67571)
to make Python 3.8 the minimum Python version for LLVM.
I edited this script because I wanted some indicator of progress while
going through files.
It now outputs `[XX/YYY]` with the number of processed and total files
after each completion.
The current version of this script is compatible downto Python 3.6 (this
is PyYAML's minimum version).
It would probably work with older Python 3 versions with an older PyYAML
or when YAML is disabled.
With the updates here, it is compatible downto Python 3.7. Python 3.7
was released June 2018.
https://github.com/llvm/llvm-project/pull/89302 is also touching this
file, I don't mind rebasing on top of that work if needed.
### Summary
- Add type annotations.
- Replace `threading` + `queue` with `asyncio`.
- **Add indicator of processed files over total files**. This is what I
set out to do initially.
- Only print the filename after completion, not the entire Clang-Tidy
invocation command. I find this neater but the behavior can easily be
restored.
When clang-tidy get an empty checks, it will throw "no checks enabled"
error and exit with non-zero return value.
It make clang-tidy's wrapper program confused when in big project some
files don't want to be checked and use `-checks=-*` to disable all
checks.
---------
Co-authored-by: Danny Mösch <danny.moesch@icloud.com>
This is a renewed attempt to land @toddlipcon's D34654. The comments on
that patch indicate a broad desire for some ability to ignore headers.
After considering various options, including migrating to std::regex, I
believe this is the best path forward. It's intuitive to have separate
regexes for including headers versus excluding them, and this approach
has the added benefit of being completely opt-in. No existing configs
will break, regardless of existing HeaderFilterRegex values.
This functionality is useful for improving performance when analyzing a
targeted subset of code, as well as in cases where some collection of
headers cannot be modified (third party source, for example).
Specifying checks using the literal style (|) in the clang-tidy config
file is currently supported but was not implemented for the
--verify-config options. This means that clang-tidy would work properly
but, using the --verify-config option would raise an error due to some
checks not being parsed properly.
Fixes#53737
I added the option -source-filter to the
`run-clang-tidy.py` script in the clang-tools-extra.
This option allows for handing over a regex, to filter out source files
from the compilation database (not run `clang-tidy` on them).
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
It contained 'thewarnings' without a space. It also fixes some odd
formatting in the text introduced by
commit dd3c26a045c081620375a878159f536758baba6e
Author: Tobias Hieta <tobias@hieta.se>
Date: Wed May 17 10:56:49 2023 +0200
[NFC][Py Reformat] Reformat python files in clang and clang-tools-extra
Adding an additional parameter to run_clang_tidy.py to accept a
directory where the clang-tidy fixes are saved to. This directory can
then be used to run `clang-apply-replacements`.
Closes#69450
Modify script to fail when some run clang-tidy
command fails. Based on run_clang-tidy.
Fixes: #65000
Reviewed By: carlosgalvezp
Differential Revision: https://reviews.llvm.org/D158929
Differential https://reviews.llvm.org/D145477 removed the check for `(yaml and args.export_fixes)` in line 303 to skip looking for the `clang-apply-replacements` binary. However, the `tmpdir` variable was set in this true branch when exporting fixes and therefore is `None` when invoking run-clang-tidy with `run-clang-tidy -p . -export-fixes fixes.yaml`.
Reviewed By: PiotrZSL
Differential Revision: https://reviews.llvm.org/D157773
The modules build trips over this frequently because there is no textual
include of the tablegen output, but the module includes it.
Differential revision: https://reviews.llvm.org/D157119
Change default behavior in Clang-tidy and skip by default
module headers parsing. That functionality is buggy and
slow in C++20, and provide tiny benefit.
Reviewed By: carlosgalvezp
Differential Revision: https://reviews.llvm.org/D156161
This is an ongoing series of commits that are reformatting our
Python code.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: MatzeB
Differential Revision: https://reviews.llvm.org/D150761
A previous patch update the clang-tidy documentation
incorrectly claiming that SystemHeaders can be provided
in the .clang-tidy configuration file.
This patch adds support for it, together with tests.
Differential Revision: https://reviews.llvm.org/D149899
Specifying checks as a string is convenient for quickly using
clang-tidy to run a handful of checks. However it is not
suitable for projects that have a long list of enabled or
disabled checks. It is specially troublesome in case one
wants to interleave comments with the checks, to explain
why they are enabled or disabled.
Currently this can be achieved via multiline strings in YAML,
but it's error-prone. For example, comments must end with a
comma for clang-tidy to continue processing the list of globs;
a missing comma will make clang-tidy silently ignore the rest
of the list.
Instead, enable passing a native YAML list to the "Checks"
option in the config file. The implementation is done such
that the old behavior is kept: a user can pass a string
or a list. We can consider deprecating passing the checks
as a string altogether in a future release, to simplify
the internal logic of the YAML parser.
Fixes https://github.com/llvm/llvm-project/issues/51428
Differential Revision: https://reviews.llvm.org/D147876
run-clang-tidy.py should only search for the clang-apply-replacements if really needed.
Reviewed By: carlosgalvezp
Differential Revision: https://reviews.llvm.org/D145477
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
- Specify that the .clang-tidy file is in YAML format.
- Document the options that may be used in the .clang-tidy file,
- Add missing documentation for existing options (User).
- Fix spurious newline after the dash that comes after every
command-line option. This was inconsistent with single-line
descriptions, which lacked a newline. The description is now
aligned with the dash and the corresponding command-line option,
more visually pleasing.
This enables documenting upcoming global clang-tidy
configuration options.
Differential Revision: https://reviews.llvm.org/D141144
This reverts commit 4240c9146248ac0a91c45dee421c6ef07709ba74.
The current solution won't work since getLocalOrGlobal does not
support returning a vector. More work needs to be put into
ensuring both the local and global way of setting the options
are available during the transition period.
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
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).
Since the checks fetch the option via getLocalOrGlobal,
the behavior is unchanged.
Add a deprecation notice for all checks that use the
local option, prompting to update to the global option.
The functionality for parsing the option will need to
remain in the checks during the transition period.
Once the local options are fully removed, the goal
is to store the parsed options in the ClangTidyContext,
that checks can easily have access to.
Differential Revision: https://reviews.llvm.org/D141000
The current way to specify CheckOptions is pretty verbose and unintuitive.
Given that the options are a dictionary it makes much more sense to treat them as such in the config files.
Example:
```
CheckOptions: {SomeCheck.Option: true, SomeCheck.OtherOption: 'ignore'}
# Or
CheckOptions:
SomeCheck.Option: true
SomeCheck.OtherOption: 'ignore'
```
This change will still handle the old syntax with no issue, ensuring we don't screw up users current config files.
The only observable differences are support for the new syntax and `-dump=config` will emit using the new syntax.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D128337
