We were treating enum constants more like regular decls, which results
in ignoring type aliases/exports.
This patch brings the handling to be closer to member-like decls, with
one caveat. When we encounter reference to an enum constant we still
report an explicit reference to the particular enum constant, as
otherwise we might not see any references to the enum itself.
Also drops implicit references from qualified names to containers, as
we already have explicit references from the qualifier to relevant
container.
Differential Revision: https://reviews.llvm.org/D158515
This fixes a false positive where a ParamVarDecl happend to be the
same name of some C standard symbol and has a global namespace.
```
using A = int(int time); // we suggest <ctime> for the `int time`.
```
Differential Revision: https://reviews.llvm.org/D153330
Instantiation pattern is null for incomplete template types and using
specializaiton decl results in not seeing re-declarations.
Differential Revision: https://reviews.llvm.org/D148158
Principal here is:
- Making sure each template instantiation implies use of the most specialized
template. As explicit instantiations/specializations are not redeclarations of
the primary template.
- Introducing a use from explicit instantions/specializaitons to the primary
template, as they're required but not traversed as part of the RAV.
Differential Revision: https://reviews.llvm.org/D148112
Certain standard library functions (e.g. std::move) are also implemented
as builtins. This patch moves filtering logic to the symbol->header
mapping phase to rather generate these references without any providers
only when we don't have a mapping.
That way we can also map them to header names mentioned in the builtin
mappings.
Differential Revision: https://reviews.llvm.org/D147449
26ff268b80c589fd9f71c1c214af77cd972642ca treated member operator calls
as explicit, while trying to treat them the same way as regular member
expressions, which should've been implicit.
Missing these references can result in false negatives in the used-ness
analysis and break builds.
Differential Revision: https://reviews.llvm.org/D147144
There is no need to add headers for builtin symbols.
Additionally, there is a bonus benefit which help eliminate some bugs -- builtin
functions are modeled as implicit FunctionDecls in the clang AST, which results in
them being treated as normal FunctionDecls in the implementation of the include-cleaner
(going through the path: ast-node -> decl -> source location -> header).
And, the source location of these built-in symbols' AST nodes is not precise (e.g. points to the first call site),
which leads to subtle behavior that inserts a header of the call site.
Differential Revision: https://reviews.llvm.org/D147213
Treating constructor calls when the type name isn't explicitly spelled
can cause spurious results, so turn them into implicit references.
This doesn't change the behaviour for constructor calls that explicitly spell
the type name, as we should see a reference through the typeloc.
Fixes https://github.com/llvm/llvm-project/issues/60812
Differential Revision: https://reviews.llvm.org/D144582
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
Summary:
This brings IncludeCleaner's reference discovery from AST to the parity
with current implementation in clangd. Some highlights:
- Handling of MemberExprs, only the member declaration is marked as
referenced and not the container, unlike clangd.
- Constructor calls, only the constructor and not the container, unlike
clangd.
- All the possible candidates for unresolved overloads, same as clangd.
- All the shadow decls for using-decls, same as clangd.
- Declarations for definitions of enums with an underlying type and
functions, same as clangd.
- Using typelocs, using templatenames and typedefs only reference the
found decl, same as clangd.
- Template specializations only reference the primary template, not the
explicit specializations, to be fixed.
- Expr types aren't marked as used, unlike clangd.
Going forward, we can consider having signals to indicate type of a
reference (e.g. `implicit` signal for type of an expr) so that the
applications can perform a filtering based on their needs.
At the moment the biggest discrepancy is around type of exprs, i.e. not
marking containers for member/constructor accesses. I believe this is
the right model since the declaration of the member and the container
should be available in a single file (modulo macros).
Reviewers: sammccall
Subscribers:
Differential Revision: https://reviews.llvm.org/D132110
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
Include-cleaner is a library that uses the clang AST and preprocessor to
determine which headers are used. It will be used in clang-tidy, in
clangd, in a standalone tool at least for testing, and in out-of-tree tools.
Roughly, it walks the AST, finds referenced decls, maps these to
used sourcelocations, then to FileEntrys, then matching these against #includes.
However there are many wrinkles: dealing with macros, standard library
symbols, umbrella headers, IWYU directives etc.
It is not built on the C++20 modules concept of usage, to allow:
- use with existing non-modules codebases
- a flexible API embeddable in clang-tidy, clangd, and other tools
- avoiding a chicken-and-egg problem where include cleanups are needed
before modules can be adopted
This library is based on existing functionality in clangd that provides
an unused-include warning. However it has design changes:
- it accommodates diagnosing missing includes too (this means tracking
where references come from, not just the set of targets)
- it more clearly separates the different mappings
(symbol => location => header => include) for better testing
- it handles special cases like standard library symbols and IWYU directives
more elegantly by adding unified Location and Header types instead of
side-tables
- it will support some customization of policy where necessary (e.g.
for style questions of what constitutes a use, or to allow
both missing-include and unused-include modes to be conservative)
This patch adds the basic directory structure under clang-tools-extra
and a skeleton version of the AST traversal, which will be the central
piece.
A more end-to-end prototype is in https://reviews.llvm.org/D122677
RFC: https://discourse.llvm.org/t/rfc-lifting-include-cleaner-missing-unused-include-detection-out-of-clangd/61228
Differential Revision: https://reviews.llvm.org/D124164
