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.
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
// 3) Otherwise, if third_party/x.h #includes third_party/y.h,
// add a mapping from y.h to x.h, and make y.h private. This
// means iwyu will never suggest adding y.h.
We were marking y.h private even when it wasn't in third_party.
R=dsturtevant
DELTA=28 (24 added, 0 deleted, 4 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=3302
// 3) Otherwise, if third_party/x.h #includes third_party/y.h,
// add a mapping from y.h to x.h, and make y.h private. This
But we weren't actually marking y.h as private. This CL does
that. It fixes an observed problem where iwyu was suggesting
we add a boost/do_not_add file, instead of the public boost
file that includes it indirectly.
A few tests have been updated to match the new semantics (I
think the test results were just wrong, before). In
particular, third_party files that are 'internal' according to
iwyu no longer get returned for by 'candidate #include'
function.
R=chandlerc
DELTA=11 (4 added, 1 deleted, 6 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=3257
//third_party/python_runtime as a location for Python.h, just like
//third_party/python2_4_3. Move the tests over to the new name in
(eager) anticipation of //third_party/python2_4_3 going away.
R=csilvers
DELTA=7 (5 added, 0 deleted, 2 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=2869
general-purpose code that decides when the user of a typedef
owns the underlying type, and it works properly with iosfwd,
so we don't need this special-casing anymore. On the other
hand, now that iosfwd is just a 'normal' io c++ header file,
we have to add it to the list of io re-exports (joining
iostream re-exports ostream, etc).
This should resolve the issues where iwyu is suggesting both
<iosfwd> and <iostream> in the same file.
R=wan
DELTA=28 (2 added, 22 deleted, 4 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=2415
Also makes it port.h's responsibility to export fnmatch
(before, it was the responsibility of either port.h or
iwyu_include_picker.cc, depending on the platform).
R=dsturtevant,csilvers
DELTA=152 (45 added, 4 deleted, 103 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1852
rather than the one clang gives us. Normally they're the
same, but can be different when the #include could be accessed
via different paths, or via symlinks (for instance, if
we #include "a/b/c.h" and compile with "-I. -Ia -Ia/b", then
we could say #include "a/b/c.h", #include "b/c.h", or #include
"c.h"). clang will, as I understand it, pick one of these
three forms arbitrarily for FileEntry::getName. We store the
name as it was actually typed in the source, and prefer it.
Obviously, the above only works for includes that already
exist. If we suggest a new include, we will fall back on
whatever clang gives us, which is an arbitrary name (in
practice, the first form seen).
R=klimek
DELTA=161 (100 added, 1 deleted, 60 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1851
It normally happens when a .cc file in one */internal/*
directory tries to include a .h file in another. This may be
a real bug -- crossing the internal boundary -- but the way to
point it out is not to replace the #include with one that
doesn't compile. With this change, we'll just keep the
#include as it is.
R=wan
DELTA=17 (17 added, 0 deleted, 0 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1734
First, the 'friend' pragma wasn't working at all, due to some
confusion about what needed to be a quoted include and what
needed to be a filepath. I've cleaned all that up, updated
the comments, and added some tests to catch that situation.
Second, I moved the handling of /internal/ to a bespoke scheme
to using the normal 'friend' scheme -- basically, all internal
files automatically are friends with everyone else in the same
'package'. This fixes a bug that caused us to map some
#include to <built-in>, when the include-chain was:
<built-in> -> foo/internal/bar.cc -> foo/internal/baz.h
Before this change, both foo/internal/bar.cc and
foo/internal/baz.h were considered private, since they are in
/internal/, so the #include of baz.h was mapped to the only
non-private "file" in the chain, which is <built-in>. After
this change, foo/internal/bar.cc is still considered private,
but it doesn't matter since it's also considered a friend of
foo/internal/baz.h, and thus allowed to #include it.
R=wan,dsturtevant
DELTA=131 (83 added, 22 deleted, 26 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1728
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
directories as specified on the compiler line, when deciding
whether to use "" or <>. Hard-code in some rules for google3
where we don't do it quite right.
To fully fix the associated bug, I also noticed that our cfoo
<-> foo.h mappings was missing stddef.h, which is defined in a
different place from other headers. I added it in.
R=wan,dsturtevant
DELTA=161 (69 added, 20 deleted, 72 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1597
map omitting the necessary quotes around the filename. The
check for this was suppressed because we shared the same code
for the filename map and symbol map. Separate out that code
so we can do the check and avoid future problems.
DELTA=30 (6 added, 10 deleted, 14 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1595
the include-picker. iwyu_test was always a terrible name,
anyway.
R=wan
DELTA=1059 (528 added, 528 deleted, 3 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1593
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
treated as private headers, and mapped to the nearest
including public header, was too strict. The basic problem:
what if 'foo/internal/baz.h' tried to include
'foo/internal/bar.h'? It should be able to. In some cases,
'foo/internal/bar.h' isn't even included from any non-internal
file, and we end up suggesting to #include <built-in> (the
only non-private include in the include-chain).
I fixed this up by adding a new function for mapping private
headers to public, that takes into account who is doing the
including. If foo/x/y/z is including foo/internal/a/b/c, we
don't say foo/internal/a/b/c is private in this context. But
if joe/otherproject tries to include foo/internal/a/b/c, then
we *do* say foo/internal/a/b/c is private, and map it to its
closest public header.
I also took out unnecessary code that marked includer-files
that are '/internal/' as private, not just included-files. We
should never need to mark includers as private; if the
includer-file is itself included in turn, we'll have ample
opportunity to mark it private then. Otherwise, we run the
risk of a file being marked private, with nobody including it
that we can map to.
To better match the new semantics that files aren't
intrinsically public or private but it depends on the context,
I renamed GetPublicHeader* to GetCandidateHeader*,
R=wan,dsturtevant
DELTA=179 (84 added, 2 deleted, 93 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1590
do this by caching when nodes are done, so we don't need to
re-compute their transitive closure multiple times.
This is necessary because the transitive-closure code is
getting to be a bottleneck, now that we have so many more
mappings because of the implicit third-party mappings.
One functional change: cycles in third-party code are now
silently ignored, rather than causing a death. This is
because some third party code -- *cough* boost *cough -- has
cycles, and we can't fix that.
R=wan
DELTA=105 (58 added, 4 deleted, 43 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1581
too aggressive: it was too likely to conflict with some of the
hard-coded values in third-party map. Plus, it's not
necessary, since we know these files are not included from any
google (non-third-party) code anyway. So remove that, and
update the tests appropriately.
R=wan,dsturtevant
DELTA=7 (1 added, 1 deleted, 5 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1578
likely we'll suggest adding an internal third-party header.
Basically, we stop trying to do include-what-you-use fixes on
third-party code.
More precisely, we make an 'implicit' judgment on which
third-party headers are public and which are private, based on
what existing code (in this translation unit) #includes. We
marked all unincluded files as private, which means iwyu will
never suggest adding a new third-party file as an #include.
Insted, it will suggest some already-included third-party file
that gets the needed file transitively.
Since it's not really practical for us to fix third-party code
to have better #include hygiene, or even to mark up third-party
code with iwyu pragmas, we need to do something similar to
this. We could just manually update iwyu_include_picker's
third_party_map with rules for every third party package we
have, but that's expensive. This is much cheaper, with the
downside that we may miss some potential include-what-you-use
opportunities in third-party code (going from a more-generic
third-party include to a less-generic one). I think that's a
low cost.
R=dsturtevant
DELTA=113 (104 added, 0 deleted, 9 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1577
includes-as-written rather than the actual file-path of the
included file. Since the include-picker deals with actual
file-paths (of the decls), this made no sense, and indeed we
were seeing when code depended on a search path, we weren't
finding the proper include-mapping for it.
For instance, python .h files has
#include "dictobject.h"
rather than
#include "third_party/python2_4_3/gcc-3.4-glibc-2.11.1-grte-k8-linux-python2.6-opt/include/python2.6/dictobject.h
Thus, while we had code that correctly mapped
third_party/python2_4_3 to <Python.h>, it wasn't firing on the
above code because the include-picker saw it as just
"dictobject.h". This is now fixed by using the actual
file-path.
While testing, I discovered the test-file was often calling
AddDirectInclude() improperly (with extra "'s). It didn't
happen to matter, but I cleaned it up.
R=wan,dsturtevant
DELTA=43 (5 added, 2 deleted, 36 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1574
for normalizing suggested #include-paths, according to chandler.
While testing this, I realized ConvertToQuotedInclude can be
significantly simpler now, since a lot of the logic that was
hard-coded in there is actually encapsulated in
GlobalSearchPaths().
This gives one minor logic change, that 'unexpected' #includes
with absolute paths will now be "/weird/include" rather than
</weird/include>, but I've never seen either happen, so it
shouldnt' matter.
R=chandlerc
DELTA=62 (55 added, 5 deleted, 2 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1572
to add globs like
"third_party/*.h" -> "third_party/include.h"
without getting into an infinite loop because include.h maps
to itself.
R=wan
DELTA=35 (24 added, 0 deleted, 11 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1567
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
from clang. We no longer need to have ad-hoc rules for
reading from system include directories, and the one rule we
do still have we've moved into a more appropriate place.
Also, a bug report showed we had left out a system private ->
public mapping we should have. I had left it out because I
wanted to be conservative with the bits/ -> bits/ mappings,
but on closer study, these new mappings seem appropriate.
R=wan,dsturtevant
DELTA=84 (24 added, 59 deleted, 1 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1276
makes iwyu.cc cleaner.
For now, we use it only for iwyu_tests.cc, which needs
InitGlobal() to be called, which needs a CompilerInstance.
DELTA=516 (285 added, 210 deleted, 21 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=919
explicitly, and is also in a glob pattern. I was just lazy
before, but with the new Extend() method, it's actually less
code now with this change!
R=dsturtevant
DELTA=19 (15 added, 3 deleted, 1 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=745
public/private information in a separate data structure from
the mapping. Besides being a bit clearer to follow, this
makes it easier to verify that we're consistent in declaring a
file public or private. We now do verify this, which turned
up a few inconsistencies in the hard-coded data (not anything
major), which I've fixed.
This prompted a bit of a change in the API, to separate out
adding of mappings from adding of public/private-ness. This
fits the iwyu preprocessor workflow better, allowing us to
resolve a TODO or two.
I've also cleaned up a comment or two.
R=wan
DELTA=186 (81 added, 60 deleted, 45 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=722
* .cxx and .cpp extensions are handled (I'm using the same list as used in IsHeaderFile() - perhaps .inl should be considered too)
* Path separators are canonicalised on Win32. Our build system provides search paths with forward slashes as separators, but paths with backslashes creep in somewhere. So foo\bar\baz.h and foo/bar/baz.h should now be considered the same.
I've added a couple of tests for the first case to the testsuite, but the README suggests that there's no framework for the 'more_tests' tests yet. When this is available I'll add some extra tests for separator canonicalisation.
There are a few TODOs:
* CanonicalizeFilePath should probably collapse '../' sequences, i.e. a/b/../c and a/c should be considered the same (this is handled nicely by PathCanonicalize on Win32, perhaps there's a nice Unixy equivalent?)
* We should probably ignore case on Win32.
(BTW there is a 'canonicalize()' function in llvm/Support/FileSystem.h which would do what we want, but it doesn't seem to be implemented :/ )
Resolves
http://code.google.com/p/include-what-you-use/issues/detail?id=15
Patch submitted by paul.hol...@gmail.com and reviewed by csilvers
* 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.
1) Removed the use of <tr1/tuple> -- it wasn't getting us that much,
and cost us in portability. Resolves
http://code.google.com/p/include-what-you-use/issues/detail?id=2
2) Removed unused 'using' statements, renamed some vars to be cleaner,
added 'const' in a few places I could, etc.
3) Refactored some logic into a new function GetCalleeFunctionType().
4) Made a few tests more robust by using better fakes (mostly in
more_tests, so not directly relevant to the opensource code).
5) Added a check to make sure we don't add any new include-mappings
after we were supposed to have finialized the mappings.
All code reviewed by wan and/or dstur...
Kim Grasman