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.
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.
`run_iwyu_tests.py --run-test-file <file>` runs IWYU for <file> without
initializing `unittest.TestCase` classes.
Moving the code that generates tests into `__main__` allows to early
exit before test classes would be created. That saves the execution time
by not enumerating all the test files in order to create the test
classes and functions.
`run_iwyu_tests.py --list-test-files` prints the list of tests and test files separated by a colon.
Example:
```
$./run_iwyu_tests.py --list-test-files
c.test_elaborated_struct:tests/c/elaborated_struct.c
c.test_keep_includes:tests/c/keep_includes.c
cxx.test_alias_template:tests/cxx/alias_template.cc
cxx.test_alias_template_use:tests/cxx/alias_template_use.cc
cxx.test_anonymous_struct:tests/cxx/anonymous_struct.cc
cxx.test_array:tests/cxx/array.cc
...
```
`run_iwyu_tests.py --list` prints the list of all tests.
Example:
```
$./run_iwyu_tests.py --list
c.test_elaborated_struct
c.test_keep_includes
cxx.test_alias_template
cxx.test_alias_template_use
cxx.test_anonymous_struct
cxx.test_array
...
```
Currently each test source file `{dir}/{name}.{ext}` creates a test case
with `{name}` name. Files in different root `{dir}`s but with same {name}s
can end up with a name collision, so test runner just adds suffix '2'
to the name of test suite to avoid collisions. If a developer wants to
only run a specific test using `run_iwyu_tests.py {name}` it might be
difficult to figure out which exactly test failed.
This change adds extra layer of hierarchy (scoping) for tests.
Having 'C' and 'Cxx' tests this change introduces 'c' and 'cxx' TestCase
classes. As before, test runner walks down the `tests/` subtree, and
populates test case classes with `test_{filename}` methods automatically.
Test name examples before and after this change:
+---------------------+---------------+-----------------------
| File Name | Test Before | Test After
+---------------------+---------------+-----------------------
| c/keep_includes.c | keep_includes | c.test_keep_includes
| cxx/using_unused.cc | using_unused | cxx.test_using_unused
It also becomes possible to run C or Cxx tests only:
```
run_iwyu_tests.py c
run_iwyu_tests.py cxx
```
When using sizeof(T) in a forward-declare context, the argument (T)
should *not* be considered to be in a forward-declare context. Fix and
add test case.
Placement new is special in that using it requires including <new>.
badinc.cc had some test coverage for placement new, but it was
relatively free-standing from the rest of the badinc machinery, so move
it to a dedicated test file. In the process lost one seemingly-pointless
test that 'delete (((newed_int)));' does not require <new>.
Add test cases to cover placement new:
* of builtin types in normal code
* of user-defined types in normal code
* in a macro
* in an uninstantiated function template
* of an instantiated class template
Add testcases for new(std::nothrow) and new(std::align_val_t), which
uncovered a bug: they should not require <new> for operator new, but
they _should_ do so for the placement symbols. Mark undesirable
diagnostics with TODOs for now, will be fixed in upcoming patch.
This replaces builtins_new_included.cc with operator_new.cc, and covers
all variants of operator new that do _not_ require <new> to be
included:
- Raw explicit ::operator new/::operator delete calls
- New expressions, both of builtin and user-defined types
This was detected by an assertion in iwyu_output.h:
Assertion failed: desired_includes_have_been_calculated_ &&
"Must calculate desired includes before calling
desired_includes()"
This came about because there are two parallel structures for headers:
* IwyuFileInfo: direct includes, as quoted include strings
* IwyuPreprocessorInfo: files to report iwyu violations for, as
FileEntry pointers
The assertion fires if a header ends up in IwyuFileInfo but not in
files-to-report, and iff that header is an associated header.
Therefore, make sure we call AddGlobToReportIWYUViolationsFor in all
places where we classify something as an associated header.
A minimal repro case is:
// tests/cxx/x.cc
#include "y.h"
#include "tests/cxx/x.h"
#include "x.h"
if include-what-you-use is invoked with the absolute path of x.cc.
Our current test infrastructure doesn't support absolute paths for the
test target, so this can't be reproduced. Add a test to exercise the
problematic path even if it doesn't trigger the assertion.
Root-causing and original fix by Nick Overdijk, tests and rationale by
Kim Gräsman.
Fixes issue #738.
.moc files are handled by a separate Qt preprocessor called 'moc', which
expands them into C++ code.
They are not C++ in and of themselves, and can't be safely analyzed by
IWYU. The moc preprocessor allegedly suggests to remove unused .moc
includes, so we should leave them alone.
Implement this by pretending '--keep="*.moc"' was passed on the
command-line.
Fixes issue #721.
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.
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.
This fixes a case where IWYU would suggest include paths with ".." where
a simpler non-".." path would suffice. E.g.
// a.h
struct Symbol {};
// foo/b.h
#include "../a.h"
// main.c
#include "foo/b.h"
Symbol s;
IWYU would suggest we should include "foo/../a.h" from main.c here. This
is correct, but inelegant.
After this patch, we'll suggest "a.h" directly. Unfortunately, this is
broken in the face of symlinks (example cut from bug report) --
akuli@Akuli-Desktop:~$ ln -s /usr a
akuli@Akuli-Desktop:~$ file a
a: symbolic link to /usr
akuli@Akuli-Desktop:~$ file lib
lib: cannot open `lib' (No such file or directory)
akuli@Akuli-Desktop:~$ file a/../lib
a/../lib: directory
akuli@Akuli-Desktop:~$
-- but I suspect this is more unusual than relative includes.
Fixes issue 690.
I've always found the extra underscore a detriment to readability.
Update all filenames and content in one fell swoop.
Unfortuntely built_ins_with_mapping.imp changes so much that Git's
content tracking gets lost and sees it as a new file. Original commit
details here:
e00e5f1f09
Author: John Bytheway <jbytheway@gmail.com>
AuthorDate: Thu Mar 7 21:55:44 2019 +0000
Stop ignoring uses for builtins with mappings
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>.
No functional change.
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.
The range-init expression requires special treatment: it's a reference
type, but the language generates code that needs to see its complete
type.
Fix#463.
InstantiateImplicitMethods() wrongly assumed a ctor decl must be
present just by checking that it is not a template decl. This is
no longer true in C++11 where a using decl is also a valid ctor type.
Fixes#402
Typedefs are exempted from IWYU checks in templates, so treat C++11
alias declarations the same.
(side note: this behavior is broken, but at least now it's consistent)
Fixes issue #412.
Sometimes IWYU's auto-detection of associated headers is insufficient.
Add an IWYU pragma to explicitly set associated header.
This is based on an original patch by Ivan Koster.
I added a test and some documentation.
Also considered options of not populating `macro_users_` or
`direct_includes_as_fileentries_` for prefix headers but decided not to
do so. I think it is better to have correct information for prefix
headers but not to give recommendations based on that instead of having
incomplete information.
PR https://github.com/include-what-you-use/include-what-you-use/pull/410
I've made a few trade-offs in implementation which I'd like to explain more.
First, code doesn't distinguish between guarded internal headers and
headers with x-macros. They are handled the same way. But in tests both
patterns are tested. It is done not to cover all code paths but to test
include-what-you-use from user's perspective.
Also I check if file defining macro is immediate includer. I decided not
to check if it includes file using the macro transitively until we have
such real-life use cases. Current implementation is strict in order to avoid
unexpected results.
For some cases I am reusing mechanism that keeps files included with the
"IWYU pragma: keep" comment. The downside is that it keeps all lines
including this file which might be not entirely correct for x-macros.
Though x-macros are close to pure textual includes and we cannot reason
about textual includes.
I also didn't include a few test cases because I think they don't
represent real-life use cases. These test cases are:
* when associated header is included by non-associated header;
* when file defining macro and file using macro are both included by the
third file.
For pointer arithmetic, the compiler needs to know the size of the
pointed-to types.
Detect all valid forms of pointer arithmetic and report both the
right-hand and left-hand expression types.
This has been a long-standing issue with IWYU (see issues #5, #271 and
probably others) where ConvertToQuotedInclude generates absolute paths
if IWYU is invoked with the current directory different from the source
file path.
This patch moves most path building to use absolute paths and path of
the includer (rather than the cwd) to produce better results.
This reverts commit 5fe99b054b.
It hits assertion
iwyu_include_picker.cc:986: Assertion failed: filepath_visibility_map_[quoted_filepath_pattern] == vis Same file seen with two different visibilities
I've made a few trade-offs in implementation which I'd like to explain more.
First, code doesn't distinguish between guarded internal headers and
headers with x-macros. They are handled the same way. But in tests both
patterns are tested. It is done not to cover all code paths but to test
include-what-you-use from user's perspective.
Also I check if file defining macro is immediate includer. I decided not
to check if it includes file using the macro transitively until we have
such real-life use cases. Current implementation is strict in order to avoid
unexpected results.
Note, that file using macro should be included with #include, not with
defines LLONG_MIN, LLONG_MAX and #include_next system <limits.h> which
on Mac OS X uses [2] LLONG_MIN and LLONG_MAX in C++11 mode.
For some cases I am reusing mechanism that keeps files included with the
"IWYU pragma: keep" comment. The downside is that it keeps all lines
including this file which might be not entirely correct for x-macros.
Though x-macros are close to pure textual includes and we cannot reason
about textual includes.
I also didn't include a few test cases because I think they don't
represent real-life use cases. These test cases are:
* when associated header is included by non-associated header;
* when file defining macro and file using macro are both included by the
third file.
[1] http://clang.llvm.org/doxygen/limits_8h_source.html
[2] http://opensource.apple.com/source/Libc/Libc-1082.20.4/include/limits.
The test running framework would always add `-I .` as an argument
to Clang. This makes it very hard to test examples without explicit
include paths, and has driven IWYU's behavior to assume the presence
of `-I .`.
In order to fix bugs related to this, we now make `-I .` explicit
for the tests that actually need it.
Patch by Flamefire, thanks!
Add an optional command-line argument to run_iwyu_tests.py, to specify
which IWYU binary to test with. Usage example:
$ ./run_iwyu_tests.py -- ./include-what-you-use
The '--' delimiter is used to separate args going to Python's unittest
from the new arg used by the test runner.
Update docs to mention new run_iwyu_tests.py features.
Seth R. Johnson