The Each construct was nice, but it's outlived its usefulness, the range for
loops are both easier to read and write.
For iteration over maps, we consistently use 'auto' to avoid repeating the map
value type.
NULL/0 -> nullptr
C standard library include -> C++ counterparts
Occasional use of auto
Explicit strcmp return value check
Remove unused usings
Closing comments for anonymous namespaces
- 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
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
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
of determining whether a value is in a non-map container.
Contains(key) only works for map-like containers.
R=csilvers
DELTA=23 (12 added, 2 deleted, 9 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1568
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
Bolshakov