- 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
Clang r256359 removed `getOptionalExplicitTemplateArgs` on various Expr
subclasses. Use
`void copyTemplateArgumentsInto(TemplateArgumentListInfo &List) const`
instead.
`const ASTTemplateKWAndArgsInfo *getTemplateKWAndArgsInfo() const` doesn't look
like appropriate replacement because it checks only `HasTemplateKWAndArgsInfo`
and we'll need to do `hasExplicitTemplateArgs()` checks ourselves.
On Windows builds of Clang/IWYU -fdelayed-template-parsing
is enabled by default. This means parsing of (function) templates
is delayed until instantiation time. If a template is never
instantiated, it is never parsed.
This is terrible behavior for IWYU, where we must traverse code
in templates looking for uses, whether they're ever instantiated
or not. So we run a separate pass that force-parses all late-
parsed FunctionDecl, building their AST before IWYU analysis.
Fixes a number of prefix_header tests that were previously failing
on Windows.
Changes of particular note:
* Resolved merge conflicts in:
third_party/llvm/libcxx/src/exception.cpp
third_party/llvm/llvm/tools/clang/lib/Driver/Tools.cpp
third_party/llvm/llvm/tools/clang/tools/driver/cc1_main.cpp
* Manual edits to
third_party/llvm/llvm/tools/clang/lib/Tooling/Tooling.cpp
due to diagnostic classes renaming
* Fixed up Cymbal, Grok and IWYU code for various class renamings
R=chandlerc,csilvers,chrsmith
Revision created by MOE tool push_codebase.
MOE_MIGRATION=3337
This fixes an issue I ran across where I couldn't inhibit the forward declaration
of a symbol defined in an anonymous namespace.
R=csilvers
DELTA=59 (53 added, 0 deleted, 6 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=3326
I don't know how to word some of the comments -- in particular, I don't
know reasons besides not ever being instantiated for the definition
to be unknown at this point.
One big change here: GetDefinitionForClass always returns a RecordDecl.
R=csilvers,chandlerc
DELTA=43 (0 added, 24 deleted, 19 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=3312
arguments using the 'precomputed cache'. In such situations,
it totally ignored the currently active resugar_map, replacing
it with one of its own. That worked fine for types outside of
templates, but not fine for types inside (such as a 'hash_map<T>'
inside a templated class).
I "fixed" this. "Fixed" is in quotes because this turned up a
whole slew of other problems I don't even attempt to resolve
here (though I spent a few hours trying). One is that it's
possible to have a type like hash_map that has some arguments
that are dependent and some that aren't; in theory, for these
types, we can correctly attribute the use to the template
author or template instantiator depending on which type it
is. But I can't figure out how to get clang to do any
meaningful analysis of incomplete (dependent) types, so I've
punted on that for now.
The second thing wrong is I jumped through all sorts of hoops
to handle default template arguments correctly, so if a class
has a hash_map<T> and you instantiate T with string, you're
also made responsible for hash<string>. This *should* work,
but clang is giving hash<string> a type I don't expect
(RecordType, not TemplateSpecializationType), and I don't know
how to deal with that -- I don't know how to extract the
'string' part of this RecordType. Ugh. I punt on this now,
as well.
Even in this incomplete form, it's enough to resolve a P1 bug,
so I figure it's worth putting in.
R=dsturtevant
DELTA=141 (97 added, 7 deleted, 37 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=3147
statements for cast, isa, and dyn_cast. I don't know what's
changed (maybe upstream took out a using statement somewhere
that we were depending on?), but it was our bad in the first
place, so I'm happy to fix it.
Because we try not to use using statements in .h files, I just
prefixed ::llvm:: there when appropriate.
R=wan
DELTA=13 (8 added, 0 deleted, 5 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=2674
to iwyu). Fixes a crashing bug when they occur, due to a
failed assert elsewhere in the code that we only
forward-declare classes.
R=dsturtevant
DELTA=33 (32 added, 0 deleted, 1 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=2414
struct, and an unused var in non-debug mode.
R=wan
DELTA=3 (0 added, 0 deleted, 3 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1977
Remove duplicate forward declare suggestions. The problem arises if
two analyses of the same file suggest forward declarations with
differently-named template arguments.
R=csilvers
DELTA=54 (48 added, 0 deleted, 6 changed)
Change on 2011-05-04 10:05:05-07:00 by csilvers
While exploring another bug regarding default template
parameters, I ran across this one, where we wrongly required a
full type when none was available. This bug, at least, is
easy to fix.
R=dsturtevant
DELTA=44 (36 added, 0 deleted, 8 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1737
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
distinguish it farom GetClassRedecls. I've decided to keep
the two separate since classes and not-classes are treated
very differently in iwyu, so iwyu code shouldn't (I don't
think) be calling a common function for both. If that proves
to be wrong, we can combine them later, but I want us to at
least be thinking about whether it's the right thing to do.
R=wan
DELTA=14 (4 added, 0 deleted, 10 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1607
a signal to iwyu that it should not use its
stricter-than-required rules for typedefs and autocasts (that
is, iwyu requires the full type for Foo in 'typedef Foo
MyTypedef' while C++ does not).
It's a 'first shot' because we make no attempt to deal with
template arguments that may appear in underlying types. But
otherwise, it should be pretty complete.
Along the way -- not entirely related, but showed up in
testing -- fixed a place where we were declaring a use where
we shouldn't have been: when forward-declaring a template
type, we were were saying we 'used' the type we were
declaring. This isn't true: a declaration isn't a use.
Normally it didn't cause any problems (the declaration and use
are in the same file!) but it did in the test, because it was
a forward-decalred explicit specialization, which is I guess
something I'd never done before.
R=wan,dsturtevant
DELTA=628 (567 added, 18 deleted, 43 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1602
functions, typedefs, etc. We just require one of the redecls
to be visible, not all of them.
This fix isn't perfect -- we just check for redecls in the
same file as the use, and don't do all the complicated stuff
we do to pick the 'best' #include for a redecl if necessary,
like we do for forward-declarations. (The situation is
different, since we are willing to suggest adding a new
forward-decl for a class, but not for these other types like
functions.) But it's still better than it was before.
Submitting TBR since it's the weekend, and this is a
pre-requisite for getting the big typedef fix in.
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1600
should really just work on both normal classes and class
templates. Changed the API so it does.
R=wan
DELTA=71 (30 added, 13 deleted, 28 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1596
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
* Refactored some ast-checking routines into iwyu_ast_util.
* Use more 'clang'-y logic to decide what decl comes first.
* Improved comments and readabilty a bit.
R=wan
DELTA=73 (49 added, 18 deleted, 6 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1561
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
instantiation was using the resugar-map wrong: it wasn't
treating compnent types properly. In this case, we don't want
all component types, but only the actual template argument
types. (However, we do want to do a *separate* full-use check
on each of the component types.)
This manifested as iwyu saying we need full-type information
for Foo in set<Foo*>. This fixes that, and beefs up the
relevant tests.
It also fixes issue
http://code.google.com/p/include-what-you-use/issues/detail?id=27
R=wan,dsturtevant
DELTA=50 (39 added, 6 deleted, 5 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1277
at that point we had already lost info about what
specialization of the template we might be using. We have to
report at TemplateSpecializationType.
This seems like a small change, but was surprisingly difficult
to get right. I ended up having to change from reporting it
as a type to reporting it as a decl, which shouldn't matter
but does, probably indicating some fragility elsewhere in
iwyu. I did notice some other fragility problems, such as
GetClassDefinition() converting from a templated class to its
non-templated sibling, which I've fixed up.
I also fixed a bug in iwyu_output.cc where it would seem to
ignore definitions in the same file for things that only need
to be forward-declared. I'm not sure why this never came up
before; probably some other part of the codebase covered for
us (at least usually). But it seems obviously correct that if
we define a class in foo.cc, that should count the same as
defining it in one of the files foo.cc #includes. That's done
now.
R=dsturtevant
DELTA=208 (131 added, 51 deleted, 26 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1080
crux of the change is that the InstantiatedTemplateVisitor no
longer takes a set of types-of-interest, but instead takes a
map called the resugar_map. The resugar map is a tool to deal
with the fact that clang canonicalizes all substituted
template types (the "T"'s in a written template), so if you
say
typedef int MyTypedef;
template<class T> void MyFunc() { T foo; }
MyFunc<MyTypedef>();
clang will say the body is 'int foo;', not 'MyTypedef foo;'.
This is difficult for include-what-you-use.
There's one entry in the resugar map for every template
parameter. Each entry has the form <canonical-type,
type-as-written>, to make it easy to map from the canonical
type back to the type-as-written. When the type-as-written
has component types (e.g. both Foo* and vector<Foo> have a
component type of Foo), there is also an entry for each
component type.
Both template classes and template functions have a
complicating factor. For template classes, it's default
template args, which are *not* written by the caller and
usually want to attribute to the function-author. We store
these in the resugar map with a value of NULL, to indicate
they are default arguments that have no as-written form.
For template functions, likewise some or all template
arguments may be omitted by the caller, in which case the
compiler derives them from the function arguments. We do
something similar, looking for plausible mappings between
types-as-written in template functions (or their components)
and the clang-derived template arguments. This part could
still use improvement. To really do it right, we'd need to
refactor SemaTemplateDeduction to take an argument to not
canonicalize deduced template arguments.
In InstantiatedTemplateVisitor, we use the resugar-map
to beef up CanIgnoreType() and ReportTypeUse(). We ignore
types that are not in the resugar map (and thus do not
correspond to template arguments as typed). When we do use a
type, we resugar it before reporting its use. The net result
is that we should see much lower incidence of clang reporting
a weird dependency because of a type that the template-caller
has never even heard of.
We also use the fact we can tell an argument is a default
template argument to decide if the template-author or the
template-caller is responsible for the type. We say the
template-caller is *unless* the author intends-to-provide the
type, based on #includes. This handles the case when
hash<T> uses the default implementation (in stl_hash, which
stl_hashtable.h #includes) vs when it uses a user-provided
implementation (which stl_hashtable.h obviously doesn't
#include).
Implementation-wise, we needed to beef up HandleFunctionCall
to pass around the calling Expr, which holds the template
arguments as written in some cases. We also needed to update
the cache to handle the new data structures.
Administrative note: wan reviewed this but had to bow out
before finishing all the back-and-forth, and dsturtevant
reviewed it but didn't feel qualified to judge entirely, so
take the "R=" below with a grain of salt. This may require
more work in the future.
R=wan,dsturtevant
DELTA=1173 (852 added, 138 deleted, 183 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1077
file. When you reach >1300 lines long, you deserve your own
.cc file. :-)
No functionality should change -- the only changes I made were
to get rid of the clang:: prefix now that I live in a .cc
file and to combine lines that got short enough as a result.
R=dsturtevant
DELTA=1738 (955 added, 714 deleted, 69 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=904
correctly identifying when something was a class argument if
it happened to be a typedef. Desugar first so we can make the
determination properly. This makes badinc output a bit more
sensible since now operations that modify iterators actually
depend on the iterator type.
R=dsturtevant
DELTA=7 (4 added, 1 deleted, 2 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=896
handling of elaborated types at all, but instead was because
RecursiveASTVisitor changed from calling
TraverseNestedNameSpecifier to TraverseNestedNameSpecifierLoc
for most nns's. We didn't subclass
TraverseNestedNameSpecifierLoc so we were missing a lot of
NNS's.
This CL backs out the previous change, and replaces it with code to
intercept and handle NNSLoc's. The end result is the same --
badinc.cc is down to two failing tests (which are perhaps
unrelated to the clang upgrade, but instead due to changes to
iwyu itself).
I also fixed up the last two remaining badinc failures.
They were both caused by a type that I expected to be a
TemplateSpecializationType, but was actually an
ElaboratedType, because it was std::vector<...>. (So maybe
there *was* a change wrt elaborated types in the clang code.)
I audited iwyu_ast_util.h to make sure I was putting
RemoveElaboration() calls in all the necessary places.
Hopefully I got them all...
In tracking this down, I found another bug in the same area
(nested template specializations), but I'll deal with that in
a different CL.
R=dsturtevant
DELTA=132 (75 added, 43 deleted, 14 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=895
handled, which broke iwyu in several different ways. We
didn't notice at the time because run_iwyu_tests was silently
broken and not running any tests. Now that that's fixed, we
see the trouble.
This CL fixes a few of the problems -- more remain that I
haven't been able to figure out yet. Basically, an elaborated
class type (a superclass in something like Foo::FooSubclass)
is now stored as an elaboratedtype that's a sibling to
FooSubclass, rather than as a NestedNameSpecifier that's a
parent to FooSubclass. I'm not sure I understand why, but
that's not my job...
The main fix is to add a new IsClassElaborationQualifier()
function, which abstracts out the test for whether we're a
superclass in a context like Foo::FooSubclass. We now use
that both for regular types and for template-argument types.
Another, seemingly unrelated fix -- that may be due to a
different change in clang -- fixes the handling of
typedefs-to-typedefs. I don't know why they worked before,
actually, so maybe this was a bugfix in clang.
More or less unrelatedly, also do a few style cleanups in the
preprocessor file.
R=dsturtevant
DELTA=51 (39 added, 2 deleted, 10 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=892
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
match. This is necessary when the input is NULL.
R=dsturtevant,wan
DELTA=7 (3 added, 0 deleted, 4 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=724
sizeof_reference, varargs_and_references, template_function_arg.
2. Add code to print a given ASTNode, no matter what kind of node it is.
3. Print the node contents in the ast-node flattener, at debug level 7.
All code written by csilvers, and reviewed by wan and dsturtevant.
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