Clang 125f4457a54a550846732763ee36b1447ec8d66e changed.
The LLVM project is migrating from llvm::Optional to std::optional.
We would previously see llvm::Optional via an indirect include:
iwyu_preprocessor.h
iwyu_output.h
clang/AST/Decl.h
clang/AST/APValue.h
clang/Basic/LLVM.h
Since we don't use it, remove the using-declaration.
Signed-off-by: Petr Bred <bredpetr@gmail.com>
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.
Rename ForwardDeclareInKeepRange to ForwardDeclareIsMarkedKeep, take a
NamedDecl and move all location and text wrangling into the function.
This is a layering violation in a sense, because the preprocessor
doesn't know anything about declarations. But the API is much cleaner
that way from the callers' perspective -- they typically just have a
decl and shouldn't be trusted to use the right location info.
No functional change.
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.
Clang 854c10f8d185286d941307e1033eb492e085c203 changed
PPCallbacks::InclusionDirective and Preprocessor::LookupFile to use
clang::OptionalFileEntryRef instead of llvm::Optional<FileEntryRef>.
Update our overrides and calls to match.
* 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.
this was a proposed issue in #1095 where one could
make a block of keeps as opposed to marking every
keep with a pragma: keep instruction.
added test to verify and updated documentation
where appropriate.
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.
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.
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>
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.
The keys in the filepath_include_map_ are quoted includes. When these
are relative includes they are context-dependent, which means they might
not match the values elsewhere in the map. That can cause the
transitive closure operation on the map (to resolve exports of exports)
to fail.
When adding exports from pragmas, try adding them with two different
keys -- the quoted include as written, and the quoted include as deduced
from the filename. We need the former to match mapping files and the
latter to match paths generated within the code. Having both should
make both uses cases work.
When a header was included via a ""-style include relative to the
including header, and that header was marked private, the privateness
wasn't noticed, because the conversion to quoted include was variable
(it could be used as-written, or converted from a path with or without
the context of an including file).
Add a new visibility map for paths rather than quoted includes so these
can be tracked thereby.
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.
Update FileSkipped override to use the new type.
There may be opportunities for us later to store the FileEntryRef to get
at the name as-used-when-opened, but for now just try to get back to a
buildable state.
This is part of Google's original open-sourcing of IWYU.
They keep third-party libraries in a directory called, well,
'third-party', so there was lots of special casing for code in
that directory.
Remove that code, unit tests covering it and explicit mappings.
Keep one special case for allowing include cycles for files with
'internal/' in the name, to avoid breaking the include_cycle test
case. Not sure what to do about that longer term, but I didn't want to
remove the test case right now.
Clang r350891 changed the raw lexer so it asserts for IWYU's use
case.
Instead of re-lexing to catch symbols inside defined(), use a
PPCallbacks::Defined override to capture the tokens directly
(presumably, Defined did not exist when the open-coded parser was
added).
This removes a lot of code, including the PPCallbacks for If and Elif,
which are no longer necessary.
No functional change.
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.
IWYU pragma: private, include "foo" and
IWYU pragma: no_include "foo" both require quoted includes for their
arguments, but only had assertions to validate.
Add more explicit error messages for invalid syntax in these pragmas.
Fixes issue #365.
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.
The Each construct was nice, but it's outlived its usefulness, the range for
loops are both easier to read and write.
For iteration over maps, we consistently use 'auto' to avoid repeating the map
value type.
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 removal of duplicates is now countered by recording the included FileEntry
of all include lines marked "IWYU pragma: keep", and then marking all includes
of said FileEntry as desired.
We think that if the user goes to the trouble of marking an include line with
the keep pragma, they can probably explicitly remove additional includes of
that header manually if they're not wanted.
For some STL containers it is hardcoded how to handle template arguments. But
code detecting specified containers cannot detect these containers in libc++.
This commit fixes detecting containers with precomputed template arguments in
libc++.
The heuristic used to find the associated header of the main file
involved checking the name of the first file included.
When --pch_in_code is provided, the first file included is _always_
the precompiled header and can't be the associated header.
Have the heuristic check the second header with --pch_in_code.
Based on patch by David Punset, thanks!
IWYU now supports a new --pch_in_code switch which indicates the first
include directive in the translation unit is a precompiled header.
Precompiled headers are treated as prefix headers, even though they
were not specified on the command-line, but they can never be removed.
Finally, they sort first in include lists generated by IWYU, because
most compilers require the PCH to be included before anything else.
Keep FileEntry for the files defining macros, find FileEntry by quoted include
for placement operator new.
Known problems: added 2 tests fail on Windows due to issue #129 "Unused
templates are ignored on Windows".
In Clang r205398 anonymous entities are enclosed in parentheses instead of
angle brackets. I.e. it was "<anonymous namespace>" and became
"(anonymous namespace)".
Please, note that at iwyu_output.cc:140 angle brackets are used for template
specialization, not for anonymous entity, so it's correct to use angle brackets.
Both terms were used for the same concept (a header with the same base name as its associated source file, e.g. foo.h/foo.cpp) inconsistently within the code base.
No functional change.
--prefix_header_includes controls presence of includes and forward declarations
involving files included via command-line option -include. Issue is reported by
Max Dyckhoff.
Petr Bred