... instead of legacy add_definitions and include_directories.
Move compile options to after target is defined.
Batch abstract target properties with set_target_properties, looks nicer
than setting them individually.
* Use hanging closing parentheses for multiline invocations consistently
* Shorten overlong lines to colwidth 80
* Consistent placing of PRIVATE keyword
* Add space after if
Rather than recomputing use-flags for decl and using-decl (if one exists),
compute it once into a temporary.
Remove gratuitous const to fit other use-flags expression on one line.
Clang d79ad2f1dbc2db63121620f55d6cfa915f2733ac changed the File parameter from
const FileEntry* to Optional<FileEntryRef>. Parameter is unused in our
implementation, so this is only type system gymnastics.
When a consteval function is called, its call-expression is wrapped in a
ConstantExpr in the Clang AST. There's an upstream bug [1] where Clang
doesn't account for that when searching the AST for a cast-expression's
potential user-defined conversion function, leading to an assertion
failure or a crash.
Reimplement GetConversionFunction so it works in this case. This can
safely be reverted when the upstream bug is fixed.
[1] https://github.com/llvm/llvm-project/issues/53044
Two new options:
--error: sets the exit code to use if there are IWYU violations
--error_always: sets the exit code to use whether there are IWYU
violations or not
Add tests to capture all relevant combinations of
(no warnings, warnings) x
(--error, --error_always) x
(explicit arguments, default values)
and make sure --error_always overrides --error.
Exit with EXIT_FAILURE if the command-line arguments are invalid or
Clang fails to parse the input. Otherwise exit with EXIT_SUCCESS.
Add tests to capture this new policy.
It is now possible to append a parenthesized exit code to the summary start
marker: '/**** IWYU_SUMMARY(1)' to indicate that IWYU should return exit
code 1 for this test.
The exit-code syntax is only parsed out of the main file under test (not
e.g. check-also or associated files).
The exit code marker is entirely optional, and most tests shouldn't care
about exit codes.
For tests that don't really pertain to language, but have more to do
with driver details, e.g. argument parsing.
Add reusable indirect/direct headers up-front.
Clang 0d9b91524ea4db3760791bba15773c386a26d8ec renamed the MacroInfo
'tokens_iterator' to 'const_iterator', and broke our code. Use the more
abstract range iteration over 'tokens' instead for nicer code and backwards
compatibility.
CodeAuthorWantsJustAForwardDeclare uses location information to see whether the
there's a forward-declare hint earlier in the same file.
Implicit decls do not have locations, so assume the author (actually the
compiler itself) does not intend to provide hints to IWYU.
I've found no way to test this in a self-contained example. It was originally
reported in issue #1005 as an assertion triggered by the AArch64 target's
implementation of va_list:
$ cat /tmp/test.c
#include <stdarg.h>
void test(void) {
va_list args;
}
$ include-what-you-use --target=aarch64-linux-gnu -c /tmp/test.c
include-what-you-use: ...SourceLocation.h:433: ...
Assertion `Loc.isValid()' failed.
Aborted (core dumped)
Since I don't want the test suite to depend on environment (in this case,
particular targets being available), I'll leave it untested.
The change was introduced in the llvm-project repo here:
105c913156
The goal is to be able to pass a nullptr directory
to the LookupFile function if we are not interested
in retrieving the current directory, instead of
creating a dummy variable that is not used after
the function is called.
Fixes#996
Clang added a new AST node in
https://github.com/llvm/llvm-project/commit/e1600db19d6303f84b995acb93, which
shows up in the AST instead of a desugared type.
The presence of a using declaration would be omitted in the AST in favor of the
target type.
Outside of the test suite, we noticed this for <cstdint>, where the integer
types would show up as TypedefTypes in the AST, despite being pulled in via
using-declarations. They now show as UsingTypes. UsingType represents a new
so-called sugar type introduced by way of a using declaration, and links to its
UsingShadowDecl, which in turn makes it possible to chase through the
using-chain.
Report a use of the UsingShadowDecl, which is resolved centrally to the
underlying target decl (desugared typedef) as well as reporting the using-decl
itself. This is consistent with the prior behavior, but should provide better
results for tracking using declarations.
In the previous commit, I merged overlooking the fact that it didn't work.
Apparently push and pull_request can be combined with schedule if they're all
dict forms; the former two can have empty values.
This will make it easier for us to detect when IWYU breaks due to upstream Clang
changes.
The default behavior for 'schedule' is to run the build for the default branch,
so it only applies to our master branch.
IWYU currently warns for this example:
$ cat test.c
#include <inttypes.h>
#include <stdio.h>
int main(void)
{
uint64_t x = UINT64_C(1234);
printf("%" PRIu64 "\n", x);
return 0;
}
$ include-what-you-use test.c
test.c should add these lines:
#include <stdint.h> // for UINT64_C, uint64_t
test.c should remove these lines:
The full include-list for test.c:
#include <inttypes.h> // for PRIu64
#include <stdint.h> // for UINT64_C, uint64_t
#include <stdio.h> // for printf
---
However, the C standard states that "the header <inttypes.h> includes
the header <stdint.h>". So, this program shouldn't need to include
<stdint.h>.
Some mappings were previously added for individual symbols from
<stdint.h> (e.g., commit 24f9fdf0af ("Add more mappings for
[u]intptr_t"), but it's more accurate to export everything. Get rid of
the symbol mappings and add an include mapping.
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.
Apart from being easier to read by humans, this improves the cooperation
with other tools (e.g. Jenkins' warnings-ng plugin, various Emacs modes)
quite a bit. As an example, here the previous output:
Foo.h:1:1: error: add the following line
class Bar;
Foo.h:18:1: error: remove the following line
#include "Bar.h"
Foo.cc:1:1: error: add the following line
#include "Baz.h" // for Huey, Dewey, Louie (ptr only)
Foo.cc:19:1: error: remove the following line
#include "Blah.h"
With this patch:
Foo.h:1:1: error: add 'class Bar;'
Foo.h:18:1: error: superfluous '#include "Bar.h"'
Foo.cc:1:1: error: add '#include "Baz.h"' (for Huey, Dewey, Louie (ptr only))
Foo.cc:19:1: error: superfluous '#include "Blah.h"'
libclang-NN.so recently changed versioning schemes, and it doesn't look like the
Debian packages have caught up.
We don't use this file, so placate CMake by creating an empty placeholder.
Kim Gräsman