This is the unadorned result of:
git grep -En "\w.*return .*;" -- ':!tests/*' | grep-format
Having return statements on their own line makes it easier to set
breakpoints in most debuggers.
No functional change.
This change is driven by the idea of switching to FileEntry/FileID-based
way of calculating IWYU violations.
Currently IWYU calculates the difference between presented and desired
imports by comparing the list of strings (OneIncludeOrForwardDeclareLine::line),
but it would probably be easier and more reliable to operate with
FileEntries and FileIDs to determine the unused imports and their
locations.
In order to switch from a string-based solution all the
"stringly"-represented imports should be replaced with a corresponding
FileEntry or a FileID.
This change uses the preprocessor to lookup the FileEntry for `<new>`
in the corner case that reports the "placement new" symbol usage.
To signal that the use refers to an explicit instantiation, for which the
"canonical" decl is not suitable.
Also, since it is meant to be used in a specific context, the ReportDeclUse
prototype has been adapted to take optional extra flags as an additional
input.
Now that we can provide context for uses with use flags, we can tweak
IWYU behavior when a function is being defined.
This allows us to treat a function definition as a use of all
previously-seen declarations.
Fixes#179, #491 and #441.
In cases where a declaration is generated using a macro, iwyu was
incorrectly suggesting to include the file that defined such macro
instead of the actual location where it was ultimately expanded.
When reporting the declaration for a use, make sure to always refer
to the expansion/instantiation of such declaration. Whether or not
it was part of a macro expansion should be irrelevant for the use.
Fixes#282
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.
- 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.
This was caused by the fact that IWYU, when encountering a UsingDecl, adds everything that the UsingDecl could refer to as a forward declarable. Because IWYU automatically upgrades function decls to a full use (ie: not forward declarable), unnecessary includes are added based on unused functions.
This change alters the logic as follows;
- Remove the code that adds the UsingShadowDecls of an encountered UsingDecl.
- Record the fact that we've encountered a UsingDecl and mark it as un-used.
- Add support to the Record* functions such that when encountering a UsingShadowDecl, we can know we're accessing a Decl through a UsingDecl.
- Mark referenced UsingDecl as 'used' when accessed through a UsingShadowDecl.
- At the end of processing, if a UsingDecl has not been referenced, arbitrarily add one of the symbols it is referencing so that we don't remove all headers it refers to and break compilation.
The change also adds several unit test that catch variations of this problem an demonstrate that they're fixed.
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.
Refactor CalculateDesiredIncludesAndForwardDeclares so it
doesn't implicitly remove duplicate #include lines or forward
declares.
Rather, it keeps track of all of them, and then explicitly
cleans out duplicates.
This is a preparatory step for fixing issue 140.
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".
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.
This was motivated by an attempt to understand how iwyu_ast_util.cc
depended on iwyu_output, which turned out to be the use of VERRS.
I split the VERRS definition out into a separate iwyu_verrs module.
In the fallout from this I discovered some circular dependencies
that this CL attempts to disentangle.
R=csilvers
DELTA=603 (349 added, 222 deleted, 32 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=3892
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
(because, say, a .h was included twice and didn't have a
header guard, so all its content was repeated). Fix this by
doing a uniqueness check when adding #includes.
We could speed this up by storing a map, but typically a file
doesn't have so many includes that a quadratic-time algorithm
over them is going to matter.
R=dsturtevant
DELTA=77 (75 added, 0 deleted, 2 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=3315
messages that iwyu produces (and that are shown with
--mode=why for iwyu.py). Use this ability to comment two
non-obvious warnings we give: when requiring a full use
because of autocasting (one-arg, not-explicit constructor),
and when requiring a full use for the return type of a
function declaration. Update appropriate existing tests to
check for the comment when appropriate.
R=wan,dsturtevant
DELTA=173 (82 added, 25 deleted, 66 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1726
accessible 'commandlineflags' struct. This replaces the
rather ad-hoc collection of variables and functions, spread
across 3 different files, that we have now. The motivation is
adding a new commandline flag that I want to be visible in yet
a fourth file; I figured that was a good time to consolidate.
Now iwyu_globals holds everything.
R=wan,dsturtevant
DELTA=306 (161 added, 112 deleted, 33 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1591
use a type via a using declaration, we need to make sure to
use that using declaration as well. It may be in a different
file from the type!
There may be corner cases we don't handle right yet, but we do
the right thing at least most of the time. One case we don't
handle is when there's a using declaration but we ignore it
('using foo::a; foo::a = 1'). We'd do better if clang would
report whether a given decl-use was via a using declaration or
not, but right now it doesn't. cf:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-April/014564.html
(though that applies only to using vars, not functions).
In order to implement this reasonably, I had to (finally!)
unify the type and decl reporting in iwyu.cc, rather than
iwyu_output.cc. This allows me to remove a bit of duplicated
code, and also makes the logic easier to follow.
R=dsturtevant
DELTA=358 (286 added, 71 deleted, 1 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1576
broken -- it left out the common case that the class is being
used inside the outer class without a qualifier. A new test
shows where we would do the wrong thing in that case.
Fixing this brought up more problems, that could all be traced
to the fact we 'cheat' and create fake uses of
forward-declares when we want to be sure not to delete them.
I get rid of the cheating and just say, when we see a
forward-decalare, whether we want to definitely-keep it or
not. That yields much nicer code (I think).
I also don't know what I was thinking when I said "if there
are multiple fwd-decls in a class, just keep one arbitrarily."
Obviously we should keep the first one; the arbitrary one may
come too late. These changes brought that bug to light too
(an existing test started failing), but now it's squashed.
Finally, I resolved a TODO, getting rid of
IsDeclNodeInsideFriend. I had known this was possible for a
while, I just had never gotten around to actually doing it.
Doesn't affect any tests.
R=dsturtevant
DELTA=141 (75 added, 26 deleted, 40 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1453
test some main()-invariant logic while I'm at it.
DELTA=19 (16 added, 0 deleted, 3 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1409
thought I was saying the location is where the . (or ->) is,
which is what I want, but clang doesn't actually expose that.
So I have go through some hoops to try to figure it out.
We were actually seeing a problem with this when running:
blaze build --host_cpu=k8 --compile_only -k --crosstool_top=//third_party/llvm/crosstool --plugin=//devtools/maintenance/include_what_you_use:run_iwyu //gws/plugins/local/src:enhanced_listing_ad
It has 'msg_->MSG_foo' in it, where MSG_foo is a macro. We
were attributing this use to the file defining MSG_foo, rather
than to us. With this change, we properly attribute it to us.
R=dsturtevant
DELTA=150 (125 added, 6 deleted, 19 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1347
Usage: // IWYU pragma: no_include "foo/bar/baz.h"
This inhibits IWYU from suggesting that baz.h be included.
R=csilvers
DELTA=109 (98 added, 1 deleted, 10 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1339
situations are ones where iwyu requires a full definition but
the language allows a forward-declare. This causes trouble in
cases like:
class Foo;
typedef Foo Bar;
class Foo { ... };
In this case, we require the full definition of Foo for the
typedef, which leads us to believe the forward-declaration is
extraneous, even though it's actually necessary.
I fix this by detecting when iwyu wants a definition that
occurs after the use, and making iwyu want the
forward-declaration then as well.
While testing this, I found some bugs in the existing code
that tries to handle forward-declarations inside classes -- it
wasn't handling uses in initializers (which should be treated
like method bodies) or the implicit destructor code. I added
logic (and tests) around those.
I also discovered a bug where GetDefinitionAsWritten() was
sometimes converting templated class to the untemplated
CXXRecordDecl version. GetDefinitionAsWritten() should
preserve the templated-ness of is argument. It does so better
now.
R=dsturtevant
DELTA=159 (135 added, 5 deleted, 19 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=739
'include what you use' mantra when it came to forward
declares: before this CL, it said, "if someone you are
#including from forward-declares a class for you, you don't
have to forward-declare that class yourself." But that means
you can't refactor .h files to remove unnecessary
forward-declares. If you need to forward-declare something,
you should forward-declare it yourself, not get that fwd-decl
from an #include.
(Note the story is different if you're getting the
*definition* of a class from an #include, even if you only
need a forward-declaration for that class. In that case,
using the #include is fine. The only thing this CL addresses
is when you try to use a .h file to forward-declare something
for you.)
R=dsturtevant
DELTA=206 (137 added, 41 deleted, 28 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=727
* Add support for FakeNamedDecls for tests (dsturtevant)
* Write our own symbol sanitizer rather than getQualified... (csilvers)
* Change run_iwyu_tests to better fit python test framework (csilvers)
* Revamp IWYU pragmas, now support keep + export + private (dsturtevant)
* Fix a bug when nested classes are defined out of line (csilvers)
* Add the ability to print an arbitrary ASTNode (csilvers)
All code by csilvers was reviewed by wan and dsturtevant. Code by
dsturtevant was reviewed by csilvers.
Kim Gräsman