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.
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.
- 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
If two paths in the header search set shared the same prefix, IWYU would
sometimes pick the wrong one and produce an invalid quoted include. For
example:
Header search path: /a/foo, /a/foobar
File path: /a/foobar/header.h
This would yield "bar/header.h", as "/a/foo" was considered a basename of
the file path.
We fix this by ensuring all search path entries end with "/" up-front.
I didn't add a test for this, because an end-to-end test would be almost
nonsensical. Once we get the unit test suite up and running, I'd like to
add a test for this there instead.
- No longer necessary to define _POSIX_ for MSVC builds
- Remove some cruft from port.h
- Remove unused direct.h/unistd.h includes
- Clean up includes in iwyu_path_util.h
- No functionality change intended
- Tested on Win32/MSVC + Linux/GCC
Search for mapping files:
- in the current working directory;
- in the directory where IWYU executable is located;
- in the directory where another discovered mapping file is located.
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
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
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
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
Kim Grasman