This is a powerful tool when doing iterative refined matches,
where another match is started inside the match callback of the first
one; this allows for example to find out whether the node was in
the condition or body of its parent if-statement.
llvm-svn: 174605
name lookup has been performed in that context (this probably only happens in
C++).
1) Whenever we add names to a context, set a flag on it, and if we perform
lookup and discover that the context has had a lookup table built but has the
flag set, update all entries in the lookup table with additional names from
the external source.
2) When marking a DeclContext as having external visible decls, mark the
context in which lookup is performed, not the one we are adding. These won't
be the same if we're adding another copy of a pre-existing namespace.
llvm-svn: 174577
if it found any decls, rather than returning a list of found decls. This
removes a returning-ArrayRef-to-deleted-storage bug from
MultiplexExternalSemaSource (in code not exercised by any of the clang
binaries), reduces the work required in the found-no-decls case with PCH, and
importantly removes the need for DeclContext::lookup to be reentrant.
No functionality change intended!
llvm-svn: 174576
The use of this flag enables a modules optimization where a given set
of macros can be labeled as "ignored" by the modules
system. Definitions of those macros will be completely ignored when
building the module hash and will be stripped when actually building
modules. The overall effect is that this flag can be used to
drastically reduce the number of
Eventually, we'll want modules to tell us what set of macros they
respond to (the "configuration macros"), and anything not in that set
will be excluded. However, that requires a lot of per-module
information that must be accurate, whereas this option can be used
more readily.
Fixes the rest of <rdar://problem/13165109>.
llvm-svn: 174560
This can happen when one abuses precompiled headers by passing more -D
options when using a precompiled hedaer than when it was built. This
is intentionally permitted by precompiled headers (and is exploited by
some build environments), but causes problems for modules.
First part of <rdar://problem/13165109>, detecting when something when
horribly wrong.
llvm-svn: 174554
This is in preparation for adding other overloaded matchers. This change
alone is a net win in LOC.
I went through all matchers and looked whether we could now encode them
as macro, or simplify them with the matcher atoms that were not
available before.
llvm-svn: 174540
This was GCC's option to turn on UCN support, which we always have on now
in C99 and C++ modes.
Additionally, mark the -fno-extended-identifiers option as unsupported,
since we don't support disabling UCNs in C99 and C++ modes.
PR11538
llvm-svn: 174530
With this patch, clang-format can analyze the input file for two
properties:
1. Is "int *a" or "int* a" more common.
2. Are non-C++03 constructs used, e.g. A<A<A>>.
With Google-style, clang-format will now use the more common style for
(1) and format C++03 compatible, unless it finds C++11 constructs in the
input.
llvm-svn: 174504
A very common use case is to search for the first occurrence of
a certain node that is a descendant of another node. In that
case, selectFirst significantly simplifies the code at the client side.
llvm-svn: 174499
This is a more natural order of evaluation, and it is very important
for visualization in the static analyzer. Within Xcode, the arrows
will not jump from right to left, which looks very visually jarring.
It also provides a more natural location for dataflow-based diagnostics.
Along the way, we found a case in the analyzer diagnostics where we
needed to indicate that a variable was "captured" by a block.
-fsyntax-only timings on sqlite3.c show no visible performance change,
although this is just one test case.
Fixes <rdar://problem/13016513>
llvm-svn: 174447
We found that findAll has been implemented incorrectly multiple times
by various people using the matchers. To prevent further wasted
development effort, it makes sense to add it as convenience matcher
implemented as eachOf(m, forEachDescendant(m)).
This patch also updates the docs with the new matchers.
llvm-svn: 174320
eachOf gives closure on the forEach and forEachDescendant matchers.
Before, it was impossible to implement a findAll matcher, as matching
the node or any of its descendants was not expressible (since anyOf
only triggers the first match).
llvm-svn: 174315
This combines several changes:
* Calculation token type (e.g. for * and &) in the AnnotatingParser.
* Calculate the scope binding strength in the AnnotatingParser.
* Let <> and [] scopes bind stronger than () and {} scopes.
* Add minimal debugging output.
llvm-svn: 174307
...again. The problem has not been fixed and our internal buildbot is still
getting hangs.
This reverts r174212, originally applied in r173951, then reverted in r174069.
Will not re-apply until the entire project analyzes successfully on my
local machine.
llvm-svn: 174265
designator" diagnostic with more correct and more human-friendly "cannot take
address of rvalue of type 'T'".
For the case of & &T::f, provide a custom diagnostic, rather than unhelpfully
saying "cannot take address of rvalue of type '<overloaded function type>'".
For the case of &array_temporary, treat it just like a class temporary
(including allowing it as an extension); the existing diagnostic wording
for the class temporary case works fine.
llvm-svn: 174262
Inlining these functions is essential for correctness. We often have
cases where we do not inline calls. For example, the shallow mode and
when reanalyzing previously inlined ObjC methods as top level.
llvm-svn: 174245
says, but that's a defect (to be filed). "Cls::purevfn()" is still an odr use.
Also fixes a bug that caused us to not mark the function referenced just
because we didn't want to mark it odr used.
llvm-svn: 174242
This change introduces a 'kind' attribute for the <Para> tag, that captures the
kind of the parent block command.
For example:
\todo Meow.
used to be just <Para>Meow.</Para>, but now it is
<Para kind="todo">Meow.</Para>
llvm-svn: 174216
This allows us to keep from chaining LazyCompoundVals in cases like this:
CGRect r = CGRectMake(0, 0, 640, 480);
CGRect r2 = r;
CGRect r3 = r2;
Previously we only made this optimization if the struct did not begin with
an aggregate member, to make sure that we weren't picking up an LCV for
the first field of the struct. But since LazyCompoundVals are typed, we can
make that inference directly by comparing types.
This is a pure optimization; the test changes are to guard against possible
future regressions.
llvm-svn: 174211
First, this implements a match() method on MatchFinder; this allows us
to get rid of the findAll implementation, as findAll is really a special
case of recursive matchers on match.
Instead of findAll, provide a convenience function match() that lets
users iterate easily over the results instead of needing to implement
callbacks.
llvm-svn: 174172
Introduces these negation forms explicitly and uses them to control a new
"altivec" target feature for PowerPC. This allows avoiding generating
Altivec instructions on processors that support Altivec.
The new test case verifies that the Altivec "lvx" instruction is not
used when -fno-altivec is present on the command line.
llvm-svn: 174140
Remove "IsMSDeclspec" argument from Align attribute since the arguments in Attr.td should
only model those appear in source code. Introduce attribute Accessor, and teach TableGen
to generate syntax kind accessors for Align attribute, and use those accessors to decide
if an alignment attribute is a declspec attribute.
llvm-svn: 174133
It's causing hangs on our internal analyzer buildbot. Will restore after
investigating.
This reverts r173951 / baa7ca1142990e1ad6d4e9d2c73adb749ff50789.
llvm-svn: 174069
In cooperation with the LLVM patch, this should implement all scalar front-end
parts of the C and C++ ABIs for AArch64.
This patch excludes the NEON support also reviewed due to an outbreak of
batshit insanity in our legal department. That will be committed soon bringing
the changes to precisely what has been approved.
Further reviews would be gratefully received.
llvm-svn: 174055
Douglas Gregor