summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeLines
* tests/: Fix includesoffsetofAlejandro Colomar2023-08-12-6/+10
| | | | Signed-off-by: Alejandro Colomar <alx@kernel.org>
* Add mapping for offsetof(3)Alejandro Colomar2023-08-12-0/+2
| | | | Signed-off-by: Alejandro Colomar <alx@kernel.org>
* Reduce libc mappings to really include what you useAlejandro Colomar2023-08-12-299/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Remove packaging workaround to fix llvm-18 buildKim Gräsman2023-08-11-1/+1
|
* Add new IWYU pragma: always_keepKim Gräsman2023-07-12-1/+83
| | | | | | | | | | | | | 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.
* Move ProtectReexportIncludes to a member functionKim Gräsman2023-07-12-16/+17
| | | | | | | | | | 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.
* Improve placement-new detection in templatesKim Gräsman2023-07-06-11/+73
| | | | | | | | | | | | | | | | | | | | | | 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.
* [clang compat] Use newer DirectoryEntryRef API for header searchKim Gräsman2023-06-24-3/+3
| | | | | | | | | | | | | 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.
* Roll getopt_port to latest versionKim Gräsman2023-06-24-11/+25
| | | | | | | The new implementation corresponds to https://github.com/kimgr/getopt_port/commit/6ad8cc105b55ad9f83136129fd0c6c2a209da43e. This fixes the ambiguity issue raised in PR #1260.
* iwyu_test_util: add support for IWYU_EXTRA_ARGS env variableFlorian Schmaus2023-05-28-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Don't run include-what-you-use through shell in testsKim Gräsman2023-05-21-23/+13
| | | | | | | | | | 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.
* Identify libcxx from clang ToolChainDavid Kilroy2023-05-17-1/+20
| | | | | | | 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.
* Remove redundant InitGlobals()David Kilroy2023-05-17-1/+0
| | | | Missed in 1646cfbfbdf
* [ci] Add workaround for missing libomp package dependencyKim Gräsman2023-05-09-0/+4
|
* Add builtin libcxx mappingsDavid Kilroy2023-04-18-2/+57
| | | | | | | Automatically select the standard library that the clang toolchain identifies based on platform and command line arguments. Fixes: #306
* Add constness to some member functionsBolshakov2023-04-18-4/+4
| | | | No functional change.
* Add functions to derive standard libs from compilationKim Gräsman2023-04-16-15/+26
| | | | | | | Pass CompilerInstance directly to InitGlobals to give it access to the entire compilation state. No functional change.
* Fix elaborated type provision by aliasBolshakov2023-04-16-10/+12
| | | | | | | 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.
* Handle elaborated keywords as fwd-declsBolshakov2023-04-16-4/+59
| | | | | | | | | | | | | | | | | 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.
* Disable DerivePointerAlignment clang-format optionKim Gräsman2023-04-16-0/+1
| | | | | | | 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.
* [doc] Update documentation on test command-line argumentsKim Gräsman2023-04-16-8/+10
| | | | This was overlooked in bc0ec65ec04b46c73a7d5b2b8b29d7854c615327.
* Provide default values for class membersBolshakov2023-04-16-19/+10
| | | | | | | Otherwise, one could get an undefined behavior when forgetting to set them in a constructor. No functional change.
* libcxx: map <__tree> to <map> and <set>David Kilroy2023-04-15-0/+2
| | | | | | | | | | | | 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.
* libcxx 16 private header dir mappingsDavid Kilroy2023-04-13-4/+39
| | | | | | | | | | | | | | 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).
* libstdcxx std::declval sourceDavid Kilroy2023-04-10-1/+7
| | | | | | | | | 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.
* Bump version to 0.21 on masterKim Gräsman2023-04-02-1/+1
|
* Update README for IWYU 0.20Kim Gräsman2023-04-02-0/+1
|
* Abandon python2 for scriptsKim Gräsman2023-04-02-27/+10
| | | | | | | | | | | * 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.
* Refactor to allow stdlib selectionDavid Kilroy2023-04-02-25/+61
| | | | | | | | | | | | 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++.
* Fix run_iwyu_test.py instructions in CONTRIBUTINGDavid Kilroy2023-03-25-2/+2
| | | | | Commit 8343f0ce8aa1 modified how tests are named. Update the CONTRIBUTING instructions to align.
* [clang compat] Use new include path for Host.hDavid Kilroy2023-03-17-2/+2
| | | | | | | | | | 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.
* Log "Extra tokens" warning at higher verbosity levelKim Gräsman2023-03-15-2/+2
| | | | | | | | | 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.
* Use nominal logging from AstFlattenerVisitorKim Gräsman2023-03-13-19/+2
| | | | | | | | | | | | | | | | | 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.
* Log traversal, not visitsKim Gräsman2023-03-13-71/+57
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Simplify TraverseNestedNameSpecifierLoc slightlyKim Gräsman2023-03-12-3/+3
| | | | | | 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).
* Short-circuit all traversal of null AST nodesKim Gräsman2023-03-12-3/+13
| | | | | | | | | | | | | | | | | | 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.
* Add testcase for template-spillsKim Gräsman2023-03-05-0/+89
| | | | | | | | | | | | | | | | | | | 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.
* Remove redundant CanIgnoreType callsKim Gräsman2023-03-05-26/+9
| | | | | | | | | | 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.
* Never report ignored typesKim Gräsman2023-03-05-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Ignore null types in InstantiatedTemplateVisitor tooKim Gräsman2023-03-05-0/+3
| | | | | | | | | | | 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.
* Report explicit instantions with more discretionKim Gräsman2023-03-05-10/+167
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix incorrect affirmation in log messageKim Gräsman2023-03-05-3/+3
| | | | This message is printed when the type is _not_ a known template param.
* Refactor explicit_instantiation2 testcase for extensionKim Gräsman2023-03-02-12/+30
| | | | | | | | | | | | | | 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.
* More consistent work with resugaring mapBolshakov2023-02-26-3/+14
| | | | | | | | | | | | | | | | | | 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.
* Don't traverse under SubstTemplateTypeParmTypeBolshakov2023-02-26-32/+16
| | | | | | | | | | | 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.
* Use the correct decl location for use loggingKim Gräsman2023-02-26-2/+2
| | | | | | | | | | | | | 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()).
* Don't report into template definition fileBolshakov2023-02-25-6/+3
| | | | | | | | 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.
* [iwyu-check-license-header] Fix line length of added headerKim Gräsman2023-02-23-1/+1
| | | | | | | The line length computation was off by three dashes, because EMBELLISHMENT had three more dashes than the actual format string. Harmonize them.
* [iwyu-check-license-header] Write bytes, not strKim Gräsman2023-02-23-2/+3
| | | | | | | | 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.
* Never forward-declare expressions used in typeid()Matthew Fennell2023-02-18-0/+65
| | | | | | | | | 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.