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.
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.
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.
Boolean type is internally represented in clang as '_Bool' builtin type.
In order to display it correctly taking into account language options,
actual printing policy should be used.
Clang 9f57b65a272817752aa00e2fb94154e6eed1d0ec sometimes prints the 'final'
keyword twice for a declaration (tracking bug:
https://github.com/llvm/llvm-project/issues/56517).
This triggered several bugs in MungedForwardDeclareLineForTemplates:
* Only removed first 'final'
* Removed one character too many (sizeof(char[]) includes the trailing NUL)
Instead, replace all occurrences of 'final' and do it first so the stripping of
superclasses and body also get rid of trailing spaces. This should now work even
if the upstream bug is fixed.
This is preparation for adding suggestions for enumeration opaque
(forward) declarations. Enums should be treated almost similar
to classes and structs, so clang::RecordDecl should be replaced
by clang::TagDecl, which is a superclass for RecordDecl and EnumDecl,
in many places.
In addition to C++ methods, silence reports of all declarations inside a
class (data members, types, etc.) if the parent type has already been
reported.
Fixes#75 and fixes#494.
Add `--update_comments` option to make IWYU always print the 'why'
#include comments, regardless of whether any include lines need to be
added or removed. With this change, IWYU will update the "// for xyz"
comments as the code changes, preventing the comments from becoming
stale.
The technique used before relied on linear search of all builtins by
name. This did not work with qualified C++ names of C library names such
as std::pow and std::round.
Use ASTContext to get to BuiltinInfo, and in turn use that to check more
specific traits of the builtin by ID instead of name.
Add distinct tests for C and C++ to cover both <math.h> and <cmath>.
Fixes issue #776.
This change is driven by the idea of switching to FileEntry/FileID-based
way of calculating IWYU violations.
Currently IWYU calculates the difference between presented and desired
imports by comparing the list of strings (OneIncludeOrForwardDeclareLine::line),
but it would probably be easier and more reliable to operate with
FileEntries and FileIDs to determine the unused imports and their
locations.
In order to switch from a string-based solution all the
"stringly"-represented imports should be replaced with a corresponding
FileEntry or a FileID.
This change uses the preprocessor to lookup the FileEntry for `<new>`
in the corner case that reports the "placement new" symbol usage.
LLVM added a second boolean argument to
isReplaceableGlobalAllocationFunction() with 3dd5a298bfff ("[clang]
Annotating C++'s `operator new` with more attributes"). However both
parameters define a default argument. Hence there is no need to
explicitly state the argument, if it is already the default argument,
which is nullptr is isReplaceableGlobalAllocationFunction() case. This
also increases readability.
Before this patch, IWYU would skip past template specializations and go
for the base template when trying to find the definition for a class
template.
This led to misbehavior as reported in issue #735 so that:
// template.hpp
template<typename>
struct T;
template<> struct T<int> { int x; };
// source.cpp
#include "template.hpp"
int f(T<int>& t) { return t.x; }
would require a forward declaration of the base template in source.cpp.
Remove this step on the basis that we _are_ in fact using the
specialization, and the file containing the specialization will probably
have some declaration (or even definition) of the base template.
Instead of 'IsDefaultNewOrDelete' which uses heuristics and string
parsing, use FunctionDecl::isReplaceableGlobalAllocationFunction from
the Clang API. It returns true for any replaceable allocation function,
which happens to coincide nicely with all allocation functions except
placement new.
Fixes#777 and improves behavior for the modern allocation functions:
- Sized deallocation in C++14
- Aligned allocation in C++17
This small improvement fixes a number of TODOs in the new placement_new
testcase, and makes it possible to add a testcase for implicit aligned
allocation in operator_new, as aligned allocation no longer requires
<new>.
Patch based on work and lots of good input from Adar Dembo.
llvm/llvm-project@777180a makes the llvm::StringRef conversion operator
to std::string explicit.
These changes add a call to the str() method to perform the conversion.
Signed-off-by: Andrea Bocci <andrea.bocci@cern.ch>
Seems that's the style used elsewhere. Fixes this build error against
latest llvm-project.git:
/home/vmiklos/git/include-what-you-use/iwyu_output.cc: In function ‘bool include_what_you_use::internal::DeclCanBeForwardDeclared(const clang::Decl*, std::__cxx11::string*)’:
/home/vmiklos/git/include-what-you-use/iwyu_output.cc:727:35: error: ‘dyn_cast’ was not declared in this scope
} else if (const auto* record = dyn_cast<RecordDecl>(decl)) {
^~~~~~~~
/home/vmiklos/git/include-what-you-use/iwyu_output.cc:727:35: note: suggested alternatives:
In file included from /home/vmiklos/git/llvm/instdir/include/clang/Basic/LLVM.h:21:0,
from /home/vmiklos/git/llvm/instdir/include/clang/AST/APValue.h:17,
from /home/vmiklos/git/llvm/instdir/include/clang/AST/Decl.h:16,
from /home/vmiklos/git/include-what-you-use/iwyu_output.h:27,
from /home/vmiklos/git/include-what-you-use/iwyu_output.cc:10:
/home/vmiklos/git/llvm/instdir/include/llvm/Support/Casting.h:342:61: note: ‘llvm::dyn_cast’
LLVM_NODISCARD inline typename cast_retty<X, Y *>::ret_type dyn_cast(Y *Val) {
^~~~~~~~
/home/vmiklos/git/llvm/instdir/include/llvm/Support/Casting.h:332:5: note: ‘llvm::dyn_cast’
dyn_cast(const Y &Val) {
^~~~~~~~
/home/vmiklos/git/include-what-you-use/iwyu_output.cc:727:54: error: expected primary-expression before ‘>’ token
} else if (const auto* record = dyn_cast<RecordDecl>(decl)) {
^
Introduce an overload to DeclCanBeForwardDeclared which puts a reason in
an output parameter, so logging can say in more detail why a declaration
was not qualified for forward declaration.
Keep the old overload as a plain forward, not all call sites want or
need the reason string.
Technically users can forward-declare inline namespaces, e.g.
namespace std {
inline namespace __1 {
template <class T>
struct hash;
}
}
but that would be both confusing and problematic:
1) The symbol is referred to as std::hash, but declared here with a name
nobody should ever see.
2) When a new ABI version is added for std::hash, a new internal
namespace -- e.g. __2 -- will be added, and std::hash and
std::__1::hash no longer refer to the same symbol.
As inline namespaces are intended primarily as a versioning feature for
library authors, avoid trying to second-guess them and just require a
full use for any decl inside an inline namespace.
This fixes issue #713.
A (misspelled) comment said something about adjusting for trailing
spaces, but at that point the string had already been shortened several
times. I suspect this is just a left-over.
All tests pass with this removed, so let's revisit it with test coverage
if any bugs fall out.
If a symbol was ultimately mapped to a header which was (or should be)
included via a ""-style relative include then that would not be handled
correctly.
Update the symbol mappings to be handled in the same way as the include
mappings so that this should no longer be an issue.
Fix some corner cases that can arise due to interaction between pragma
export and includes that are relative to the including header (i.e.
includes that can only be done using "", not <>).
Because headers are mostly handled as quoted includes for the purposes
of mapping, this can go wrong with relative includes because they are
not always relative to the same place, and at some places in the code we
don't even know what they're relative to.
Fix this by tracking full paths in parallel or instead of quoted
includes in certain places.
Currently this is just a simple wrapper around a quoted include. This
provides some type safety, but no behavioural change is intended.
This lays the groundwork for adding more data to the MappedInclude
object in order to fix some bugs.
If we find a fwd-decl use with --no_fwd_decls, we see if there is already an
include that provides the decl, and if there is, we keep that include otherwise
we keep the local decl.
Before this, the --no_fwd_decls mode would force-remove existing forward
decls:
class Foo;
void Bar(const Foo*);
Add an additional rule that we avoid promoting uses of forward-
declarations in the same file to full uses, to retain forward-decls like
the above.
This makes the behavior of --no_fwd_decls simpler and more consistent:
optimize for fewer redeclarations instead of fewer includes. Whenever
there's a choice between a forward-decl and an include, choose the
include.
Add test coverage for more variants of included forward decls.
IWYU used to ignore all uses of builtins.
This makes sense normally. However, when a symbol has an explicit
mapping defined, we should not ignore uses of it.
In particular, for example, one might require a particular header to be
included when certain builtins are used, and this change allows that by
defining a mapping for that builtin.
Also, under some situations some standard library functions (e.g.
std::round) get treated as builtins. With this change IWYU respects
mappings for such builtins, and by defining them suitably it will no
longer remove #include <cmath>.
Currently if IWYU decides that the best header for a symbol is the same
one that uses the symbol, it can cause that header to add a #include of
itself.
This in particular can happen with mappings.
Detect this case and cause the use to be ignored.
Furthermore, when choosing from multiple public mapping headers, prefer
to use oneself where possible (since that minimizes #includes).
This opts in for the more concise syntax introduced in C++17: namespace
a::b { ... }.
Usage of this is especially useful in codebases where existing forward
declarations in nested namespaces already use this form: so the IWYU
suggestion for new forward declarations can be consistent with the
existing ones.
fix_includes.py already handled this, but add a test to maintain this
behavior, too.
The existing code coped poorly with the case where header A includes B
includes C includes D where D is a private header and B and C are both
public headers for a symbol in D. In this case B would be forced to
include D directly when it ought only to be including C.
Fix this by an additional condition on the special case intended to
handle these sorts of situations.
For further detail, see discussion at
https://github.com/include-what-you-use/include-what-you-use/pull/615
Also test.
To signal that the use refers to an explicit instantiation, for which the
"canonical" decl is not suitable.
Also, since it is meant to be used in a specific context, the ReportDeclUse
prototype has been adapted to take optional extra flags as an additional
input.
Don't assume that the decl for a template specialization must always be
a record. If, for example, such template is built in, the decl will derive
from TemplateDecl instead.
Also, explictly look for BuiltinTemplateDecl during post processing to
correctly identify them as builtins. If this is not done, a following
check would ignore them anyway but in that case they will be reported as
"backwards includes".
Function builtins handled now using getBuiltinID/isBuiltinFunc from clang
to identify all the predefined symbols that have no include and should be
ignored. Before, only the symbols prefixed with __builtin_ were identified.
Fixes#150
Now that we can provide context for uses with use flags, we can tweak
IWYU behavior when a function is being defined.
This allows us to treat a function definition as a use of all
previously-seen declarations.
Fixes#179, #491 and #441.
Kim Gräsman