If the current working directory of `clang-include-cleaner` differs from
the directory of the input files specified in the compilation database,
it doesn't adjust the input file paths properly. As a result,
`clang-include-cleaner` either writes files to the wrong directory or
fails to write files altogether.
This pull request fixes the issue by adjusting the input file paths
based on the directory specified in the compilation database. If that
directory is not writable, `clang-include-cleaner` will write the output
relative to the current working directory.
Fixes#110843.
Currently callers of analyze can't get detailed information about a
missing header, e.g. resolve path. Only way to get at this is to use low
level walkUsed funciton, which is way more complicated than just calling
analyze.
This enables further analysis, e.g. when includes are spelled relative
to inner directories, caller can still know their path relative to
repository root.
This patch disables all clang warnings when running include-cleaner, as
users aren't interested in other findings and in-development code might
have them temporarily. This ensures tool can keep working even in
presence of such issues.
We were using tryGetRealPathName in certain places, which resolves
symlinks (sometimes). This was resulting in discrepancies in behavior,
depending on how a file was first reached.
This path migrates all usages of tryGetRealPathName to regular getName
instead.
This implies one backward incompatible change for header-filtering. Our
ignore-header option used to filter against suffixes of absolute paths,
whereas now filter can receive working-directory relative paths in some
cases, possibly braking existing filters.
Chances of really braking users is pretty low:
- We'll still filter against absolute paths when header is outside the
working directory (e.g. /usr/bin/include/some/linux/header.h.)
- Most projects run builds in a working directory that's nested inside
the repository, hence relative paths still contain all the segments
relative to repository root and anything else is unlikely to be
meaningful. e.g. if a header is in
`$HOME/work/llvm-project/clang-tools-extra/header.h` with builds being
run in `$home/work/llvm-project/build`, we'll still filter against
`../clang-tools-extra/header.h` which has all the useful segments as a
suffix.
- This is also a change in how we handle symlinks, but this is aligned
with what we do in rest of our tools (clangd, tidy checks etc.). We
tend to not resolve any symlinks for the file.
Our internal integration relies on injecting some default values to
ignore/keep lists.
That means we can have filters, despite of not having occurences
for the flag.
We have a previous fix
be861b64d9,
which snapshots all processing files.
It works most of times, the snapshot (InMemoryFileSystem) is based on
the file path. The file-path-based lookup can fail in a subtle way for
some tricky cases (we encounter it internally), which will result in
reading a corrupted file.
This is a different fix, we don't modify files on the fly, instead, we
write files when the tool finishes for all files.
Snapshot all analysing files before running the tool, this makes sure
that we analyse all files statelessly and avoid the FileManager caching issue
when running `-edit` on multiple files.
Differential Revision: https://reviews.llvm.org/D155195
The fixIncludes was using the `input` as the main file path, this will
results in inserting header at wrong places.
We need the main file path to so that we can get the real main-file
header.
Differential Revision: https://reviews.llvm.org/D154950
If the source code is compilable-but-layering-violation, we still want
the tool to be functional on it (rather than bailing out).
Differential Revision: https://reviews.llvm.org/D154477
The binary tool only works on working source code, if the source code is
not compilable, don't perform any analysis and edits.
Differential Revision: https://reviews.llvm.org/D153271
This adds command-line flags to the tool:
+ -print: prints changed source code
+ -print=changes: prints headers added/removed
+ -edit: rewrites code in place
+ -insert=0/-remove=0: disables additions/deletions for the above
These are supported by a couple of new functions dumped into Analysis:
analyze() sits on top of walkUsed and makes used/unused decisions for
Includes. fixIncludes() applies those results to source code.
Differential Revision: https://reviews.llvm.org/D139013
Demo: 7911d8251c/PathMapping.cpp.html
Header insertion doesn't actually work that well (not this patch's fault):
- we don't have ranking of locations/headers yet, so inserted header is pretty
random
- on my system, we get a lot of absolute "/usr/bin/../include/..." paths.
This is a HeaderSearch bug introduced in D60873 that I'll send a fix for
Differential Revision: https://reviews.llvm.org/D138676
The immediate goal is to start producing an HTML report to debug and explain
include-cleaner recommendations.
For now, this includes only the lowest-level piece: a list of the references
found in the source code.
How this fits into future ideas:
- under refs we can also show the headers providing the symbol, which includes
match those headers etc
- we can also annotate the #include lines with which symbols they cover, and
add whichever includes we're suggesting too
- the include-cleaner tool will likely have modes where it emits diagnostics
and/or applies edits, so the HTML report is behind a flag
Differential Revision: https://reviews.llvm.org/D135956
