Clang 125f4457a54a550846732763ee36b1447ec8d66e changed.
The LLVM project is migrating from llvm::Optional to std::optional.
We would previously see llvm::Optional via an indirect include:
iwyu_preprocessor.h
iwyu_output.h
clang/AST/Decl.h
clang/AST/APValue.h
clang/Basic/LLVM.h
Since we don't use it, remove the using-declaration.
Signed-off-by: Petr Bred <bredpetr@gmail.com>
The full type use reporting in the three covered cases is ensured
with excessive `CanIgnoreType` calls which check not only the type
to be reported but also the type before dereferencing (which occurs
to be in the resugaring map). This approach should be refactored
in subsequent commits.
Using type deduction, a function can define a local type and return it:
auto func() {
struct X {};
return X();
}
Before this change, IWYU would register X as a use for callers of func.
In certain situations (union inside lambda inside macro) this would lead
to a forward-declare use trying to format a forward-declaration of the
type local to the function in PrintForwardDeclare. This led to a crash
since the lambda was unnamed, but there's really no point trying to
forward-declare a type that is private to a function.
Generalize this so we ignore all uses of symbols declared inside a
function. In order to get in contact with that symbol, we must already
have access to the function, so the containing header must already be
included.
Fixes issue: 795
Covers both begin_export/end_export blocks and single-line export
pragmas.
Like with 'IWYU pragma: keep' marks the forward decl as automatically
desired to avoid removing manually exported but unused decls.
Add a simple testcase and update documentation.
Rename ForwardDeclareInKeepRange to ForwardDeclareIsMarkedKeep, take a
NamedDecl and move all location and text wrangling into the function.
This is a layering violation in a sense, because the preprocessor
doesn't know anything about declarations. But the API is much cleaner
that way from the callers' perspective -- they typically just have a
decl and shouldn't be trusted to use the right location info.
No functional change.
`clang::UsingType` denotes a sugar type which is introduced by a using-
declaration (e.g., `using ns::SomeType;`). It has not such a special
meaning in IWYU as `TypedefType` or `TemplateSpecializationType`.
No functional change is expected.
Previously, ReportDeclUse was called for TypedefDecl when TypedefType
is passed to ReportTypeUse. This change short-circuits that path. But
an underlying type should still be reported if the typedef doesn't
"provide" it. Hence, corresponding logic is moved into ReportTypeUse.
So ReportDeclUse reports typedef declarations and ReportTypeUse reports
typedef underlying types now.
In December 2018, the header clang/Frontend/FrontendDiagnostic.h moved
to clang/Basic/DiagnosticFrontend.h. The old header was left around for
compatibility.
Use the new one instead.
Sorry I'm late.
The core AST nodes (Decl, Stmt, Type, TypeLoc) all have a kind denoting
their specific derived type, and a corresponding function to get a
printable string for the kind.
Implement a polymorphic GetKindName that calls the right function
depending on type, and also adds a suffix to mirror the clang class
name.
Make all uses of the get...Name functions call these wrappers instead.
No visible change intended.
Report fwd-decls only for explicitly written types
There is no point in reporting forward-declaration of a type when just
its pointer is used and the type is not explicitly written
in the source. Explicitly written pointer types are handled, e.g.,
in VisitTemplateSpecializationType and VisitTagType.
Add test cases for redundant fwd-decl absence
This is the unadorned output of:
git grep -En "^\s*=" -- ':!tests/*' | grep-format
There are some examples with comments between the variable name and the
'=' that clang-format left unchanged.
No functional change.
This is the unadorned result of:
git grep -En "\w.*return .*;" -- ':!tests/*' | grep-format
Having return statements on their own line makes it easier to set
breakpoints in most debuggers.
No functional change.
This function had some bad indentation that disagrees with clang-format.
To prepare for some changes and make their diff more focused, reformat
up-front.
In very particular circumstances (see test case), VisitFunctionDecl
would see a function definition that was an implicit constructor of a
builtin (va_list_tag).
Rather than crashing for implicit code, just say it's not in a header.
This feels a little questionable, because depending on how IsInHeader is
used, it might be misleading that it returns false for builtins/implicit
code. But I think it makes sense for now.
Fixes issue #1162.
The v2 action depends on deprecated Node.js 12, as indicated by warning
from GitHub Actions:
Node.js 12 actions are deprecated. For more information see: [1].
Please update the following actions to use Node.js 16:
actions/checkout@v2
(See [2] for an example.)
Upgrade to actions/checkout@v3 to silence the warning.
Unfortunately this new version has a very confusing policy for default
checkout ref: "[...] the last merge commit of the pull request merge
branch". There does not appear to be a convenient way to fall back to
the v2 behavior.
Add some conditional logic to resolve the HEAD of the right branch
whether it's a schedule, push or pull_request event.
[1] https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/.
[2] https://github.com/include-what-you-use/include-what-you-use/actions/runs/3718310359
Clang 854c10f8d185286d941307e1033eb492e085c203 changed
PPCallbacks::InclusionDirective and Preprocessor::LookupFile to use
clang::OptionalFileEntryRef instead of llvm::Optional<FileEntryRef>.
Update our overrides and calls to match.
A long-standing problem with IWYU has been the preprocessor
metaprogramming techniques used in Boost.
IWYU is fine with cycles in the include graph, but did not accept cycles
in the corresponding mapping graph (a potential rationale might have
been to let people know if they explicitly added contradictory mappings,
but we really don't know what drove this decision).
Looking at the algorithm expanding the transitive closure of the mapping
graph, it expands all nodes in depth-first order. Cycle detection is
necessary to protect the algorithm from infinite recursion in the
presence of a cycle. But there should be no difference in the transitive
closure between a graph with cycles and one without. DFS will still
visit all nodes, it will just avoid visiting the same subtree twice.
Once the expansion is done, mapping lookup is an inherently
non-recursive operation (made cheaper by performing the recursive
expansion up-front). See the GetCandidateHeadersForFilepath family of
functions and their respective callers.
Two conclusions:
* Cycles are already detected by the transitive closure algorithm
* No code _after_ the transitive closure is affected by any cycles
Therefore, update the transitive closure expansion to ignore cycles
instead of failing on them. Add diagnostic logging at level 8 so we can
look into its decision-making if necessary.
Fixes issue #424
Non-sugared template specialization type template arguments are already
analyzed due to 'TraverseType' call inside
'InstantiatedTemplateVisitor::TraverseSubstTemplateTypeParmTypeHelper'
and subsequent 'TraverseTemplateSpecializationTypeHelper' call.
Components of sugared template specialization types are added into
resugar_map, otherwise their template arguments would not be reported.
Test case has been extended.
Full template specialization type use requires full information about
its template-argument-dependent fields and nested typedefs. But earlier,
it wasn't reported in many cases when template specialization type isn't
written explicitly in non-fwd-decl context.
Installation of libclang-16-dev would fail with:
Unpacking libclang-16-dev (1:16~++20221216031545+6c5f3f62bdb2-1~exp1~20221216151636.624) ...
dpkg: error processing archive /var/cache/apt/archives/libclang-16-dev_1%3a16~++20221216031545+6c5f3f62bdb2-1~exp1~20221216151636.624_amd64.deb (--unpack):
trying to overwrite '/usr/lib/x86_64-linux-gnu/libclang-16.so.1', which is also in package libclang1-16 1:16~++20221216031545+6c5f3f62bdb2-1~exp1~20221216151636.624
...
Unpacking libclang-dev (1:16.0-57~exp1~20221014130100.5) ...
Errors were encountered while processing:
/var/cache/apt/archives/libclang-16-dev_1%3a16~++20221216031545+6c5f3f62bdb2-1~exp1~20221216151636.624_amd64.deb
...
E: Sub-process /usr/bin/dpkg returned an error code (1)
Error: Process completed with exit code 100.
libclang-16-dev somehow depends on libclang1-16, and both are trying to
install the same libclang1.so.
Use --force-override switch to comfort dpkg, even though it's not
recommended in practice. See e.g. https://askubuntu.com/a/491086/852068.
Let's remove this as soon as possible.
The libclang-dev packages are actually called libclang-NN-dev, not
libclang-dev-NN, so make the glob a little more permissive to remove
more preinstalled packages.
The `python` command may not exist on a system with Python 3 installed.
See https://peps.python.org/pep-0394/ for a discussion of the commands
expected to be installed.
Since Python2 was officially sunsetted almost three years ago
(https://www.python.org/doc/sunset-python-2/), IWYU should prefer
compatibility with newer systems over older ones.
Python code in scripts is still Python3/Python2-compatible, but we will no
longer make an effort to preserve Python2 support over time.
Fixes#1096.
Commit 04f1c92537 added a mechanism that
dynamically adds a mapping from the includee to the includer in this
case:
// a.h
#if CONTROL_FLAG
void foo();
#else
void bar();
#endif
// b.h
#define CONTROL_FLAG
#include "a.h"
However, there was no check that includee and includer were different,
so regular #include guards would cause self-mappings, which would
eventually lead to cycles in mappings and assertion failures, e.g.:
Cycle in include-mapping:
<z.hpp> ->
<z.hpp>
,,,/iwyu_include_picker.cc:845: Assertion failed: Cycle in include-mapping
Aborted
Avoid this by checking if the file defining the macro is the same as the
file using it; in that case we don't need a mapping.
* Do all this logging on level 8, whether logging is on for file or not
* Always say "Add dynamic mappings..."
* Don't log quoted from->to, that's already logged in AddMapping
* State the reason dynamic mapping is added
* Include file paths where available
This should make it easier to troubleshoot strange effects from dynamic
mappings triggered by IWYU itself.
Only attempt to report decl uses of template names that have an
underlying template decl. This ignores uses of dependent templates and
potentially other such variations.
Even if that causes us to miss reporting for some valid constructs, it
allows further analysis of files that would otherwise crash IWYU.
Fixes issue #1140
Sameer Rahmani
Petr Bred