This patch provides more information to the
`PPCallbacks::InclusionDirective()` hook. We now always pass the
suggested module, regardless of whether it was actually imported or not.
The extra `bool ModuleImported` parameter then denotes whether the
header `#include` will be automatically translated into import the the
module.
The main change is in `clang/lib/Lex/PPDirectives.cpp`, where we take
care to not modify `SuggestedModule` after it's been populated by
`LookupHeaderIncludeOrImport()`. We now exclusively use the `SM`
(`ModuleToImport`) variable instead, which has been equivalent to
`SuggestedModule` until now. This allows us to use the original
non-modified `SuggestedModule` for the callback itself.
(This patch turns out to be necessary for
https://github.com/apple/llvm-project/pull/8011).
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.
This was creating discrepancy in cases where we might have a physical
file entry (e.g. because we followed a source location from a stdlib
file) and tried to find its exporters.
Some tools can register virtual buffers without identifiers into the
filemanager. Make sure we can handle pragmas in such cases.
Differential Revision: https://reviews.llvm.org/D157078
A verbatim header usually corresponds to a symbol from a header with
a pragma "IWYU pragma: private, include <foo.h>".
Currently this is only satisfied if the main file contains exactly
#include <foo.h>
In practice this is too strict, we also want to allow
#include "path/to/foo.h"
so long as they resolve to the same file.
We cannot be 100% sure without doing IO, and we're not willing to do
that, but we can detect the common cases based on paths.
Differential Revision: https://reviews.llvm.org/D155819
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
HeaderSearch uses FileEntry::getName() to determine the best spelling of a
header. FileEntry::getName() is now the name of the *last* retrieved ref.
This means that when FileManager::getFile() hits an existing inode through a new
path, it changes the spelling of that header.
In the absence of explicit logic to track the preferred name(s) of header files,
we should avoid gratuitously calling getFile() with paths different than how
the header was originally included, such as the result of realpath().
The originally-specified path should be fine here:
- if the same filemanager is being used for record/analysis, we'll hit the
filename cache
- if a different filemanager is being used e.g. preamble scenario, we should
get the same result unless either the working directory has changed (which it
shouldn't, else many other things will fail) or the file has gone/changed
inode (in which case the old method doesn't work either)
Needless to say this is fragile, but talking to @kadircet offline, it's good
enough for our purposes for now.
Differential Revision: https://reviews.llvm.org/D141478
The needed tweaks are mostly trivial, the one nasty bit is Clang's usage
of OptionalStorage. To keep this working old Optional stays around as
clang::CustomizableOptional, with the default Storage removed.
Optional<File/DirectoryEntryRef> is replaced with a typedef.
I tested this with GCC 7.5, the oldest supported GCC I had around.
Differential Revision: https://reviews.llvm.org/D140332
This reverts commit 8f0df9f3bbc6d7f3d5cbfd955c5ee4404c53a75d.
The Optional*RefDegradesTo*EntryPtr types want to keep the same size as
the underlying type, which std::optional doesn't guarantee. For use with
llvm::Optional, they define their own storage class, and there is no way
to do that in std::optional.
On top of that, that commit broke builds with older GCCs, where
std::optional was not trivially copyable (static_assert in the clang
sources was failing).
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
Based on include-cleaner's version, but:
- remove assert that can fail for input `/\<newline>* */`
- assert was also checking the wrong condition: that the prefix *differed* from
either `//` or from `/*`. Avoid use of strncmp where we can.
- add a comment that the brittleness of the text matching is intentional
Differential Revision: https://reviews.llvm.org/D138780
And use it findHeaders. findHeaders now finds all header candidates
given a symbol location (these headers will be attached with proper
signals, in a followup patch).
Differential Revision: https://reviews.llvm.org/D137698
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
- add support to PragmaIncludes to handle IWYU export/begin_exports/end_exports
pragma;
- implement an API to retrieve the direct exporter headers;
Differential Revision: https://reviews.llvm.org/D137319
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 occurrences are roots for finding used headers, like walkAST.
Includes are the targets we're matching used headers against.
Differential Revision: https://reviews.llvm.org/D136723
PragmaIncludes captures the pragma-based header-mapping information, it is used
in the "Location => Header" step to determine the final spelling header for a
symbol (rather than the header directive).
The structure is by design to be used inside the include-cleaner library
and clangd.
Differential Revision: https://reviews.llvm.org/D136071
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
