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.
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.
Some physical headers can have "conflicting" spellings, when same
filename exists under two different include search paths. e.g.
<stdlib.h>
can be provided by both standard library and underlying libc headers. In
such scenarios if the usage is from the latter include-search path,
users can't spell it directly.
This patch ensures we also consider spellings of such includes, in
addition to their physical files to prevent conflicting suggestions.
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.
Unlike Header, we really do have a preferred spelling for an include: the one
that we used to open the file.
The fact that Header is still FileEntry* makes it difficult to accidentally
use path equality when we want inode equality.
Differential Revision: https://reviews.llvm.org/D155885
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
Make sure unresolved headers are not analyzed as part of unused
includes.
Also introduces a testing fixture for analyze tests
Differential Revision: https://reviews.llvm.org/D146916
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
We preserve decls for stdlib symbols after this patch in symbol. That
way we have a more unified view of stdlib and regular decls and can provide
reacher information in applications.
Differential Revision: https://reviews.llvm.org/D138134
- replace SymbolLocation std::variant with enum-exposing version similar to
those in types.cpp. There's no appropriate implementation file, added
LocateSymbol.cpp in anticipation of locateDecl/locateMacro.
- FindHeaders is not part of the public Analysis interface, so should not
be implemented/tested there (just code organization)
- rename findIncludeHeaders->findHeaders to avoid confusion with Include concept
Differential Revision: https://reviews.llvm.org/D137825
This patch implements the initial version of "Location => Header" step:
- define the interface;
- integrate into the existing workflow, and use the PragmaIncludes;
Differential Revision: https://reviews.llvm.org/D137320
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
Introduces walkUsed, a very simple version of the public API to enable
incremental development on rest of the pieces.
Differential Revision: https://reviews.llvm.org/D136293
