- 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
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
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 Grasman