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.
- Rename the IsSystem flag to be IsAngled since that's how callers
actually use the flag.
- Since frameworks by convention use <> style includes, make sure
we treat them as Angled
Also update clangd's custom logic for frameworks accordingly.
Differential Revision: https://reviews.llvm.org/D156704
Requiring everything that wants to match Includes to depend on Record is weird.
This isn't lightweight enough that it feels perfect in Types, could be its own
header instead. But pragmatically it doesn't add bad deps, and is widely used.
Differential Revision: https://reviews.llvm.org/D139014
This is needed to accurately remove headers with tooling::IncludeHeaders in the
rare cases where <foo> and "foo" resolve to something different.
This is also nice to have in HTML report and command-line -print=changes output.
Differential Revision: https://reviews.llvm.org/D139018
This patch fixes:
clang-tools-extra/include-cleaner/lib/HTMLReport.cpp:240:51: error:
missing field 'Locations' initializer
[-Werror,-Wmissing-field-initializers]
Targets and Refs are 1:1, so merge them.
Don't sort Refs array we keep indices into. (Currently we're done using
those indices by the time we sort, but this is fragile)
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
RefTypes are distinct categories for each reference to a symbol. They
are signals indicating strength of a reference, that'll enable different
decision making based on the finding being provided.
There are 3 kinds of ref types:
- Explicit, the reference is spelled in the code.
- Implicit, the reference is not directly visible in the code.
- Ambigious, the reference exists but can't be proven as used (e.g.
overloads brought in by a using decl but not used by the code).
Differential Revision: https://reviews.llvm.org/D135859
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
