This is the unadorned output of:
git grep -En "^\s*=" -- ':!tests/*' | grep-format
There are some examples with comments between the variable name and the
'=' that clang-format left unchanged.
No functional change.
For some STL containers it is hardcoded how to handle template arguments. But
code detecting specified containers cannot detect these containers in libc++.
This commit fixes detecting containers with precomputed template arguments in
libc++.
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
This cache can only be used for containers whose template
types are all classes, which is not true of bitset. It was a
mistake to put it in in the first place. Fixes a clang
crashinb bug.
R=wan,dsturtevant
DELTA=6 (5 added, 1 deleted, 0 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=2188
1. it only works with an associative container (e.g. set or map),
2. it takes a key_value rather than a value_type.
R=csilvers
DELTA=55 (1 added, 3 deleted, 51 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1570
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
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
Kim Gräsman