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.
This is the unadorned result of:
git grep -En "\w.*return .*;" -- ':!tests/*' | grep-format
Having return statements on their own line makes it easier to set
breakpoints in most debuggers.
No functional change.
In very particular circumstances (see test case), VisitFunctionDecl
would see a function definition that was an implicit constructor of a
builtin (va_list_tag).
Rather than crashing for implicit code, just say it's not in a header.
This feels a little questionable, because depending on how IsInHeader is
used, it might be misleading that it returns false for builtins/implicit
code. But I think it makes sense for now.
Fixes issue #1162.
A function may just transmit passed-by-reference parameter somewhere.
Requirement to explicitly write forward declaration in the same file
(.cpp-file) to avoid '#include' suggestion is impractical when that type
is already fwd-declared in the corresponding header.
'Autocast' may still make sense for header-defined functions, due to
unlimited number of possible callers, so analysis of those fuctions
is kept.
Both function declaration site handling and call site handling
are changed.
Clang finally made the leap and harmonized all the Loc methods:
* getLocStart, getStartLoc -> getBeginLoc
* getLocEnd -> getEndLoc
r341573 removes the deprecated names, so update the few uses we had.
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
Scratch space locations look like "<scratch space>:line:col", but we compared
directly against "<scratch space>", which would always fail.
Move macro-arg-concatenation test from badinc to macro_location to make it
easier to detect failures in the future.
- Rename GetUseLocationForMacroExpansion -> GetCanonicalUseLocation
- Let macro authors forward-declare symbols to push responsibility
to expansion
- Symbols passed as arguments to macros are now attributed to expansion
Second commit attempt, with explicit use of spelling-location for
uses attributed to macro definition.
- Rename GetUseLocationForMacroExpansion -> GetCanonicalUseLocation
- Let macro authors forward-declare symbols to push responsbility to expansion
- Symbols passed as arguments to macros are now attributed to expansion
The location for the use of 'x' in 'sizeof(*(x))' will now point to 'x'
instead of '*'. This helps simplify future changes for reporting of macro
locations.
No functional change.
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
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
#include <vector>, then I intend-to-provide <vector>: you
don't have to #include <vector> just because I use it in my
(presumably templated) code, because I'm #including <vector>
for you. However, this logic runs before the private->public
mappings are done, so you're never actually wondering about
<vector>, you're wondering about <bits/stl_vector.h>.
In other words, if I'm #including <vector>, it's not to get
the symbols just provided by <vector>, but to get the symbols
provided by all the private headers that map to <vector> as
well.
I've changed the code that populates the intends-to-provide
map to handle this case. Now we have many fewer instances of
iwyu randomly deciding that you need to #include a file that
is only used in templated code. I think there are more
improvements to make in this area, but that will have to wait
for another day.
Another problem is that when we decided a template was
responsible for a decl, because it intends-to-provide it, we
were ignoring the decl, rather than keeping it and just
assigning its use to the template. Usually this is harmless,
but it could result in us deciding that the decl isn't used
anywhere at all, and removing an #include (from the template
file) that should be kept. In addition to fixing the relevant
code, I've updated a test to make sure that doesn't happen.
Testing showed up another issue, which is that the code for
determining decl locations was correctly handling templated
classes but not templated functions. This is now fixed.
Fixing it, unfortunately, made visible a known weakness in
IntendsToProvide, involving its ability to guess whether a
file actually intends to provide a definition for its symbols
or not, which is now a new TODO in badinc.cc.
R=dsturtevant
DELTA=285 (196 added, 66 deleted, 23 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=736
Kim Gräsman