This reverts commit e2a885537f11f8d9ced1c80c2c90069ab5adeb1d. Build failures were fixed right away and reverting the original commit without the fixes breaks the build again.
The `DiagnosticOptions` class is currently intrusively
reference-counted, which makes reasoning about its lifetime very
difficult in some cases. For example, `CompilerInvocation` owns the
`DiagnosticOptions` instance (wrapped in `llvm::IntrusiveRefCntPtr`) and
only exposes an accessor returning `DiagnosticOptions &`. One would
think this gives `CompilerInvocation` exclusive ownership of the object,
but that's not the case:
```c++
void shareOwnership(CompilerInvocation &CI) {
llvm::IntrusiveRefCntPtr<DiagnosticOptions> CoOwner = &CI.getDiagnosticOptions();
// ...
}
```
This is a perfectly valid pattern that is being actually used in the
codebase.
I would like to ensure the ownership of `DiagnosticOptions` by
`CompilerInvocation` is guaranteed to be exclusive. This can be
leveraged for a copy-on-write optimization later on. This PR changes
usages of `DiagnosticOptions` across `clang`, `clang-tools-extra` and
`lldb` to not be intrusively reference-counted.
This PR makes it so that `CompilerInvocation` needs to be provided to
`CompilerInstance` on construction. There are a couple of benefits in my
view:
* Making it impossible to mis-use some `CompilerInstance` APIs. For
example there are cases, where `createDiagnostics()` was called before
`setInvocation()`, causing the `DiagnosticEngine` to use the
default-constructed `DiagnosticOptions` instead of the intended ones.
* This shrinks `CompilerInstance`'s state space.
* This makes it possible to access **the** invocation in
`CompilerInstance`'s constructor (to be used in a follow-up).
Starting with 41e3919ded78d8870f7c95e9181c7f7e29aa3cc4 DiagnosticsEngine
creation might perform IO. It was implicitly defaulting to
getRealFileSystem. This patch makes it explicit by pushing the decision
making to callers.
It uses ambient VFS if one is available, and keeps using
`getRealFileSystem` if there aren't any VFS.
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
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
Tests that need ASTs have to deal with the awkward control flow of
FrontendAction in some way. There are a few idioms used:
- don't bother with unit tests, use clang -dump-ast
- create an ASTConsumer by hand, which is bulky
- use ASTMatchFinder - works pretty well if matchers are actually
needed, very strange if they are not
- use ASTUnit - this yields nice straight-line code, but ASTUnit is a
terrifically complicated library not designed for this purpose
TestAST provides a very simple way to write straight-line tests: specify
the code/flags and it provides an AST that is kept alive until the
object is destroyed.
It's loosely modeled after TestTU in clangd, which we've successfully
used for a variety of tests.
I've updated a couple of clang tests to use this helper, IMO they're clearer.
Differential Revision: https://reviews.llvm.org/D123668
