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.
Clang 854c10f8d185286d941307e1033eb492e085c203 changed
PPCallbacks::InclusionDirective and Preprocessor::LookupFile to use
clang::OptionalFileEntryRef instead of llvm::Optional<FileEntryRef>.
Update our overrides and calls to match.
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.
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.
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.
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.
- Remove DEVTOOLS_MAINTENANCE_ from header guards, that was a
now-unnecessary Googleism
- Fix header guard to match filename in all production code
- Fix header guard to match path in all tests
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.
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.
Change was done in Clang r169665, commit message is
"[Preprocessor] Enhance Ifdef/Ifndef/Defined preprocessor callbacks to also pass
a MacroInfo object if the identifier was a macro name."
we don't have to store it ourself anymore. A minor code
clean-up.
R=dsturtevant
DELTA=16 (4 added, 6 deleted, 6 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=3485
This will help a lot in debugging.
We don't have great testing for this code, but I tested it
manually on a file that has an iwyu pragma that maps an
include to itself (creating a cycle of size 1).
R=dsturtevant
DELTA=13 (10 added, 0 deleted, 3 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=3462
associated header files, we would use the filename as it
exists on the filesystem, not the one that is already used in
the code (due to -I). As a result, we could suggest a user
add an #include of an associated .h file, even if they were
already #including it (but typed differently due to -I).
Patch is from vasp...@gmail.com, at
http://code.google.com/p/include-what-you-use/issues/detail?id=5#c25
R=dsturtevant,chandlerc
DELTA=77 (71 added, 0 deleted, 6 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=3430
it should treat all forward declarable uses of the given symbol in the
file as full info uses.
R=csilvers
DELTA=104 (92 added, 0 deleted, 12 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=3113
Here's the new (additional) rule:
If there's is a .h in the first include of a .cc its basename
is the same as the .cc except for the extension then assume
it's the header implementing that file.
I had to modify the test framework a bit to capture test files
in subdirectories.
R=nilton
DELTA=91 (77 added, 0 deleted, 14 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=2483
identification of what is a pragma is now correct, because it must
start the comment.
R=wan,csilvers
DELTA=189 (58 added, 32 deleted, 99 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1984
If no friend is already included when symbols from the file are needed, then iwyu
will just bite the bullet and include the private header.
R=csilvers
DELTA=128 (120 added, 1 deleted, 7 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1983
// IWYU pragma: friend <glob>
Filenames matching the glob are allowed to include the file, which has presumably
been declared private.
R=wan,csilvers
DELTA=123 (106 added, 7 deleted, 10 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1719
--transitive_includes_only mode (controlled by a flag). In
this mode, we will throw out suggestions that file a #include
file b if file b is not visible in file a's transitive
includes; that is, all we do is move indirect includes to
direct includes, we never add a 'totally new' include.
While it's certainly possible for a 'totally new' include
suggestion to be correct, in our experience it's much more
commonly an iwyu error, usually because iwyu associates a use
with the wrong file. We control this by a flag so the user
can decide themselves whether they care more about false
positives or false negatives.
R=dsturtevant
DELTA=132 (123 added, 2 deleted, 7 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1592
Kim Gräsman