| Commit message (Collapse) | Author | Age | Lines |
|
|
|
| |
Signed-off-by: Alejandro Colomar <alx@kernel.org>
|
|
|
|
| |
Signed-off-by: Alejandro Colomar <alx@kernel.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The standards (ISO C and POSIX.1) guarantee that many definitions are
provided by more than one header. Programmers may #include <stdio.h>
for the definition of NULL, and be covered by the standards. However,
that's not following the include-what-you-use principle, and we should
not promote that.
Cut the mappings to the minimum: the principal header that should define
an identifier. In most cases, POSIX.1 and ISO C agree on that header,
and we use that one. In a few cases, ISO C prescribes <time.h> and
POSIX.1 prescribes <sys/types.h>; keep both, but give preference to the
one by POSIX.1, <sys/types.h>, which is smaller.
When the type or macro is not standardized, if there's a clearly
canonical header for it, keep that one; if there's not, let's keep all
of them.
Regarding C++'s <cstddef> and NULL, C++ uses nullptr. C++ code that
uses NULL is probably C-compat code, and that code should be including
the C header.
Also remove or update comments that are not up to date anymore.
Closes: <https://github.com/include-what-you-use/include-what-you-use/issues/1278>
Reported-by: Oliver Stöneberg <https://github.com/firewave>
Cc: Kim Gräsman <kim.grasman@gmail.com>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was proposed by the clangd/clang-include-fixer developers, who
already implement many of IWYU's pragma comments.
The pragma makes sense for us too, so implement it and add documentation
to describe the semantics.
Semantics and rationale suggested by Kadir Çetinkaya, as well as a
documentation draft from which I've borrowed some words.
Fixes issue #1235.
|
|
|
|
|
|
|
|
|
|
| |
We will soon use this pass to protect includes not covered by re-export,
so rename it and move it onto IwyuPreprocessorInfo, so we can access
state built up by the preprocessor.
Take the chance to modernize the implementation a little.
No functional change.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When placement-new is used in a template, and the buffer/target argument
is provided by a call to a dependent name, the placement-new expression
would not be recognized as such. This is commonplace now that
std::addressof exists:
template<class T, typename...Args>
void construct(T& buf, Args&&... args) {
// definitive placement-new below
new(std::addressof(buf)) T(args)
}
Prior to this fix, '<new>' would be suggested at the instantiation
location rather than the definition location. If the template was
defined in a file covered by IWYU analysis, IWYU would suggest to remove
'<new>' there, breaking the template.
Add a few more testcases for placement syntax in templates.
Fixes #1229.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DirectoryEntry::getName() is marked as deprecated as of clang
462bda1d562acc5a907eafe0afeb79556101c65d (June 15), so migrate to the
new recommended API.
This fixes a couple of
warning: 'getName' is deprecated: Use DirectoryEntryRef::getName()
instead. [-Wdeprecated-declarations]
warnings.
|
|
|
|
|
|
|
| |
The new implementation corresponds to
https://github.com/kimgr/getopt_port/commit/6ad8cc105b55ad9f83136129fd0c6c2a209da43e.
This fixes the ambiguity issue raised in PR #1260.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When running the tests as part of Gentoo's emerge process (in
src_test()) the tests fail due clang's include directory missing.
The emerge phase that runs the tests is performed with the application
under test still in the build directory. And this is what breaks the
IWYU tests there.
The include-what-you-use binary seems to have, amongst other, the
following default include path (as per
"include-what-you-use-0.19_build/bin/include-what-you-use -E -x c++ -
-v < /dev/null"):
ignoring nonexistent directory
"/var/tmp/portage/dev-util/include-what-you-use-0.19/work/include-what-you-use-0.19_build/bin/../../../../lib/clang/15.0.7/include"
Here,
/var/tmp/portage/dev-util/include-what-you-use-0.19/work/include-what-you-use-0.19_build/
is the build directory. Unfortunately, the whole path to the clang
include is invalid (non-existent). It will become correct once IWYU is merged
into the live filesystem.
As workaround run_iwyu_tests.py now supports IWYU_EXTRA_ARGS to be
able to provide the correct include path by invoking run_iwyu_test.py
basically like:
IWYU_EXTRA_ARGS="-I /usr/lib/clang/15.0.7/include" \
run_iwyu_tests.py \
-- ${BUILD_DIR}/bin/include-what-you-use
Related Gentoo bug: https://bugs.gentoo.org/905214
|
|
|
|
|
|
|
|
|
|
| |
Instead of formatting a haphazard string, build a list for the
command-line. Use shlex to split IWYU_ARGS (which implies these
arguments must be Unix-style quoted if quoting is necessary).
This makes it easier to add new arguments.
No functional change intended.
|
|
|
|
|
|
|
| |
It seems like HeaderSearchOpts doesn't have UseLibcxx set for
MacOS. It only seems to be set when -stdlib=libcxx has been
set on the command line. Get that the compilation is using
libcxx from clang::driver::ToolChain.
|
|
|
|
| |
Missed in 1646cfbfbdf
|
| |
|
|
|
|
|
|
|
| |
Automatically select the standard library that the clang toolchain
identifies based on platform and command line arguments.
Fixes: #306
|
|
|
|
| |
No functional change.
|
|
|
|
|
|
|
| |
Pass CompilerInstance directly to InitGlobals to give it access to the
entire compilation state.
No functional change.
|
|
|
|
|
|
|
| |
Elaborated types in typedef definitions should not be short-circuited
because they may yet require full-type info according to the IWYU
policy. Otherwise, it can result in a bug when IWYU requires a full type
neither on alias declaration side nor on using side.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
C++ doesn't require any forward-declaration after the declaration name
occured in an elaborated type with corresponding tag
(class/struct/union).
Initial support. Only those elaborated types are treated
as fwd-declarations which occur before any other declaration
of the underlying type ("owning" elaborated types).
TypeLoc is intercepted and handled instead of just the type because only
explicitly written elaborated types matter. Moreover, location
information could be used in the future for full support of treating
elaborated types as fwd-declarations, even in the "non-owning" case.
Besides, it is the more correct fix of #1065.
|
|
|
|
|
|
|
| |
This option is on by default for Google style, which means clang-format
will be very conservative when formatting pointer alignment/binding.
Disable it to help incrementally move towards desired style.
|
|
|
|
| |
This was overlooked in bc0ec65ec04b46c73a7d5b2b8b29d7854c615327.
|
|
|
|
|
|
|
| |
Otherwise, one could get an undefined behavior when forgetting to set
them in a constructor.
No functional change.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The <__tree> header defines red-black tree class used by both map
and set implementations.
When using a const set iterator, IWYU sees this being defined in
<__tree>. This doesn't happen for the map iterator (or other
map functionality that I could spot).
For consistency, map the header to both <map> and <set> so
including either header is accepted by IWYU.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update the mappings based on the layout of libcxx 16 headers.
There are a number of __$header directories which we can just
map to <$header>. Not all of these map to an actual header, so
avoid mapping __debug_utils, __fwd and __support.
Keep std::nullptr_t mapping.
Keep functional_base include and std::string symbol mappings
for libc++ 13 (which is the version currently used by MacOS
Ventura).
|
|
|
|
|
|
|
|
|
| |
std::declval is defined in <utility>. Currently libstdcxx actually
defines it in <type_traits>, so add a mapping so we suggest the
canonical include.
This also fixes a problem with MSVC builds, which don't like empty
arrays.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Update documentation to explicitly use python3
* Remove a few particularly ugly compatibility hacks
There are probably a lot more things we could do to use more idiomatic
python3, but that can happen as necessary.
This patch primarily wants to make explicit that python3 is assumed, and
python2 is no longer supported.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow independent selection of the internal standard library
mappings in IncludePicker construction. For now only the GNU
implementations are available, the alternative being no
mapping (selected by --no_default_mappings).
In preparation for an alternative C++ library, move the
current libstdc++ symbol mappings (which are kludges for how
to treat particular symbols) to a generic table that can be
shared, and add a separate table specifically for libstdc++.
|
|
|
|
|
| |
Commit 8343f0ce8aa1 modified how tests are named. Update the
CONTRIBUTING instructions to align.
|
|
|
|
|
|
|
|
|
|
| |
The header was moved from llvm/Support/ to llvm/TargetParser/ as part of a
breaking change in LLVM commit:
https://github.com/llvm/llvm-project/commit/f09cf34d00625e57dea5317a3ac0412c07292148
A warning was subsequently added in commit:
https://github.com/llvm/llvm-project/commit/a9329a96ada3
Use the new location. Also re-sort headers alphabetically.
|
|
|
|
|
|
|
|
|
| |
While it might be nice to have this diagnostic for troubleshooting, it
doesn't really matter if there are extra tokens; they are ignored.
Up the verbosity level to silently accept them by default.
Fixes issue #1207.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that logging happens as part of traversal, we don't need to
reimplement logging for the derived AstFlattenerVisitor.
This modifies the output for uninstantiated node slightly, changing
from:
[Uninstantiated template AST-node] 0x562b708c4ff0 [CXXRecordDecl]
to:
(0 in uninstantiated tpl) [ CXXRecordDecl ] 0x562b708c4ff0
notably getting the node depth as part of the annotated name, and making
the annotation format more consistent.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IWYU AST logging is implemented in Visit methods in the BaseAstVisitor
for all the archetypal AST node kinds: decls, types, stmts, nested name
specifiers, etc.
A regression in bfe1909a9cfc8c85193c0ec31d3f313c9ec66ab9 caused logging
to be suppressed for all Type nodes because Base::VisitType was no
longer called from derived (TypeLoc were still logged, which made the
problem slightly less glaring).
Cross-calling Visit methods is generally suspect since we might need to
have conflicting Visit implementations in base and derived. That design
also makes logging depend on the order in which Base::Visit is called
from derived classes, and we would previously have logging _after_ all
type visits rather than before.
Move all logging to the Traverse archetypes instead, where we also
maintain current AST node. This makes logging entirely predictable,
we'll always see a node logged before any of its WalkUpFrom and more
derived Traverse or Visit methods are called, which makes it easier to
reason about bugs in traversal.
This change reinstates correct logging of types.
|
|
|
|
|
|
| |
We might as well store the NNS-pointer in a temporary to simplify and
harmonize the following code (almost exactly the same as
TraverseNestedNameSpecifier now, save for base call).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The BaseAstVisitor is responsible for maintaining the current AST node,
which is used for parent lookups.
There's no use attempting to traverse or visit null values for the
different clang AST nodes, so exit early if we hit null-y values here.
TraverseType used to call Base::TraverseType for null qualtypes, but no
longer does so in the interest of consistency. RecursiveASTVisitor
returns immediately for null types anyway, and it's a stretch to think
that it would be able to anything more interesting.
This simplifies an upcoming change where we want to do more with the
respective clang AST nodes in the Traverse methods.
No functional change intended.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We've seen a lot of problems with template instantiations, that IWYU
mistakenly attributes implementation details in the template to the
instantiation location.
This testcase replicates a few common standard library constructs that
keep triggering this:
* Constructor uses unrelated type (Inner<T> does sizeof(detail::Detail))
* Constructor body uses try/catch (Inner<T> catches Inner<T>)
* Constructor body uses range for (Inner<T> iterates over itself)
* Operator overloads returning nested composite types (Outer returns
Inner<T>::value_type)
There are other type reporting constructs as well, but they are harder
to exercise succinctly. Assume all type reporting is covered by the same
mechanics, so we can use this as a trigger for regressions.
|
|
|
|
|
|
|
|
|
|
| |
Now that ReportTypeUse consistently handles ignored types, we don't need
to dance around them whenever we call that function.
Keep CanIgnoreType calls where they avoid problems for intermediary
analysis steps before ReportTypeUse.
No functional change expected.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CanIgnoreType is a little subtle, being a virtual method with very
different implementations for the primary visitor vs. the
instantiated-template visitor.
InstantiatedTemplateVisitor builds a resugar-map to associate canonical
types with their original spelling (e.g. re-binding canonical types to
any typedef used for template instantiation). Its derived CanIgnoreType
uses this map to determine whether Type instance can be ignored,
e.g. because it's a default template param or it's supposed to be
provided by the template, etc.
But CanIgnoreType was not used everywhere, so several paths would still
report types that were really known to be undesirable. This would lead
to types used inside templates to be reported in the instantiation
location, for example.
Change both the base and the instantiation-template implementations of
ReportTypeUse to call CanIgnoreType and always skip over ignored types.
This harmonization would not have been possible without the recent
tireless work of bolshakov-a improving resugaring and template handling
in general.
Fixes: #1004, #1110
|
|
|
|
|
|
|
|
|
|
|
| |
I believe InstantiatedTemplateVisitor::CanIgnoreType is never called
with a nullptr; I've run all the tests and a self-analysis of all source
files in IWYU without seeing a null type.
Exit early if type is null, which is also nicely symmetrical with
IwyuAstConsumer.
No functional change.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Whenever we ran into an explicit instantiation declaration/definition,
or the use of one, we would report all previously seen declarations of
it.
If the same explicit instantiation declaration showed up in multiple
headers, we might unnecessarily keep otherwise-unused #includes.
Use more discretion when reporting these uses:
* If there is a decl/defn in the same file, use that.
* If not, but one of the prior redecl is a declaration, not a
definition, prefer that, because explicit instantiation declarations
should be cheaper than their definitions
* If there are no declarations, use whatever definition is first in the
redecl chain
This should minimize the includes necessary for explicit instantiation
declarations/definitions.
Add a testcase to explicitly capture selection of explicit
instantiations, and update explicit_instantiation2 testcase for new
policy.
|
|
|
|
| |
This message is printed when the type is _not_ a known template param.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I will be making some changes to the explicit instantiation policies,
but this testcase has builtin assumptions that make that more difficult.
More precisely, it doesn't make a difference between locally defined
explicit instantiations vs. only header-defined explicit instantiations.
Split those two kinds into Template<bool> (locally defined) and
Template<short> (only from headers) to be able to make the distinction
more clearly in future changes.
No policy change.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Keys of `resugar_map` are canonical types, but `Desugar` doesn't give
canonical type if template specialization or alias is present
in the sugar chain. It may become important if `ReportTypeUse` starts
to call `CanIgnoreType` check for types stored in the cache because
the cache stores sugared types, e.g. `TemplateSpecializationType`s.
After this change, `IwyuBaseAstVisitor::VisitTemplateSpecializationType`
starts to work from `InstantiatedTemplateVisitor` in some cases
(at least, on traversal original template specialization type,
e.g. `Tpl1<Tpl2<int>>`). Hence, an empty implementation
of `ReportDeclForwardDeclareUse` is needed
in `InstantiatedTemplateVisitor`, because it should not report forward
declarations.
No functional change is expected.
|
|
|
|
|
|
|
|
|
|
|
| |
It used for template specialization traversal when such a specialization
is a template argument. But after 526827957 and c3bcb661f it becomes
redundant.
That traversal broke `CanForwardDeclareType` analysis in some cases.
'template_args' test shows some regression, but it is due to the fact
that typedef complex underlying types still aren't handled properly.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Back in 27da44e009660d8efc9726b1a4d80d8f9f063539 (Oct, 2018), the
location of the decl was precomputed and stored separately in the data
structure for uses.
Unfortunately it was only used for analysis then, not logging. Update
logging to use OneUse::decl_loc() consistently.
This clarifies log output particularly for uses with custom flags for
function definitions and explicit template instantiations, which are the
only ones where decl_loc() is different from GetLocation(decl()).
|
|
|
|
|
|
|
|
| |
Reporting of symbol usage in one file depending on another file analysis
seems strange. It could make some sense in order to note that template
definition file provides some internal stuff, but this form of analysis
depends on from which file it is performed and could not work when
performing analysis of the sole template definition file.
|
|
|
|
|
|
|
| |
The line length computation was off by three dashes, because
EMBELLISHMENT had three more dashes than the actual format string.
Harmonize them.
|
|
|
|
|
|
|
|
| |
This has apparently never been tested with python3; it fails because
write() expects bytes, not str.
Explicitly re-encode all content as utf-8, which is a reasonable
assumption for IWYU.
|
|
|
|
|
|
|
|
|
| |
The C++ spec requires expressions found in typeid() calls to be
fully-formed. Therefore, any necessary classes should not be
forward-declared.
This commit adds a new visitor that checks for typeid() calls, and
reports the necessary types to be included.
|