History log of /external/clang/include/clang/Sema/ScopeInfo.h
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
6bcf27bb9a4b5c3f79cb44c0e4654a6d7619ad89 29-May-2014 Stephen Hines <srhines@google.com> Update Clang for 3.5 rebase (r209713).

Change-Id: I8c9133b0f8f776dc915f270b60f94962e771bc83
651f13cea278ec967336033dd032faef0e9fc2ec 24-Apr-2014 Stephen Hines <srhines@google.com> Updated to Clang 3.5a.

Change-Id: I8127eb568f674c2e72635b639a3295381fe8af82
c00e4194296e994efab0e4bf64ca66737850bdf0 07-Nov-2013 Faisal Vali <faisalv@yahoo.com> This patch implements capturing of variables within generic lambdas.

Both Richard and I felt that the current wording in the working paper needed some tweaking - Please see http://llvm-reviews.chandlerc.com/D2035 for additional context and references to core-reflector messages that discuss wording tweaks.

What is implemented is what we had intended to specify in Bristol; but, recently felt that the specification might benefit from some tweaking and fleshing.

As a rough attempt to explain the semantics: If a nested lambda with a default-capture names a variable within its body, and if the enclosing full expression that contains the name of that variable is instantiation-dependent - then an enclosing lambda that is capture-ready (i.e. within a non-dependent context) must capture that variable, if all intervening nested lambdas can potentially capture that variable if they need to, and all intervening parent lambdas of the capture-ready lambda can and do capture the variable.

Of note, 'this' capturing is also currently underspecified in the working paper for generic lambdas. What is implemented here is if the set of candidate functions in a nested generic lambda includes both static and non-static member functions (regardless of viability checking - i.e. num and type of parameters/arguments) - and if all intervening nested-inner lambdas between the capture-ready lambda and the function-call containing nested lambda can capture 'this' and if all enclosing lambdas of the capture-ready lambda can capture 'this', then 'this' is speculatively captured by that capture-ready lambda.

Hopefully a paper for the C++ committee (that Richard and I had started some preliminary work on) is forthcoming.

This essentially makes generic lambdas feature complete, except for known bugs. The more prominent ones (and the ones I am currently aware of) being:
- generic lambdas and init-captures are broken - but a patch that fixes this is already in the works ...
- nested variadic expansions such as:
auto K = [](auto ... OuterArgs) {
vp([=](auto ... Is) {
decltype(OuterArgs) OA = OuterArgs;
return 0;
return 0;
auto M = K('a', ' ', 1, " -- ", 3.14);
currently cause crashes. I think I know how to fix this (since I had done so in my initial implementation) - but it will probably take some work and back & forth with Doug and Richard.

A warm thanks to all who provided feedback - and especially to Doug Gregor and Richard Smith for their pivotal guidance: their insight and prestidigitation in such matters is boundless!

Now let's hope this commit doesn't upset the buildbot gods ;)


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194188 91177308-0d34-0410-b5e6-96231b3b80d8
04fa7a33279808dc3e5117c41b5f84c40eeb7362 28-Sep-2013 Richard Smith <richard-llvm@metafoo.co.uk> Per latest drafting, switch to implementing init-captures as if by declaring
and capturing a variable declaration, and complete the implementation of them.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191605 91177308-0d34-0410-b5e6-96231b3b80d8
fad9e13f3cb85198f0ee5af620ba81cd78574faa 26-Sep-2013 Faisal Vali <faisalv@yahoo.com> Implement a rudimentary form of generic lambdas.

Specifically, the following features are not included in this commit:
- any sort of capturing within generic lambdas
- generic lambdas within template functions and nested
within other generic lambdas
- conversion operator for captureless lambdas
- ensuring all visitors are generic lambda aware
(Although I have gotten some useful feedback on my patches of the above and will be incorporating that as I submit those patches for commit)

As an example of what compiles through this commit:

template <class F1, class F2>
struct overload : F1, F2 {
using F1::operator();
using F2::operator();
overload(F1 f1, F2 f2) : F1(f1), F2(f2) { }

auto Recursive = [](auto Self, auto h, auto ... rest) {
return 1 + Self(Self, rest...);
auto Base = [](auto Self, auto h) {
return 1;
overload<decltype(Base), decltype(Recursive)> O(Base, Recursive);
int num_params = O(O, 5, 3, "abc", 3.14, 'a');

Please see attached tests for more examples.

This patch has been reviewed by Doug and Richard. Minor changes (non-functionality affecting) have been made since both of them formally looked at it, but the changes involve removal of supernumerary return type deduction changes (since they are now redundant, with richard having committed a recent patch to address return type deduction for C++11 lambdas using C++14 semantics).

Some implementation notes:

- Add a new Declarator context => LambdaExprParameterContext to
clang::Declarator to allow the use of 'auto' in declaring generic
lambda parameters

- Add various helpers to CXXRecordDecl to facilitate identifying
and querying a closure class

- LambdaScopeInfo (which maintains the current lambda's Sema state)
was augmented to house the current depth of the template being
parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth)
so that SemaType.cpp::ConvertDeclSpecToType may use it to immediately
generate a template-parameter-type when 'auto' is parsed in a generic
lambda parameter context. (i.e we do NOT use AutoType deduced to
a template parameter type - Richard seemed ok with this approach).
We encode that this template type was generated from an auto by simply
adding $auto to the name which can be used for better diagnostics if needed.

- SemaLambda.h was added to hold some common lambda utility
functions (this file is likely to grow ...)

- Teach Sema::ActOnStartOfFunctionDef to check whether it
is being called to instantiate a generic lambda's call
operator, and if so, push an appropriately prepared
LambdaScopeInfo object on the stack.

- various tests were added - but much more will be needed.

There is obviously more work to be done, and both Richard (weakly) and Doug (strongly)
have requested that LambdaExpr be removed form the CXXRecordDecl LambdaDefinitionaData
in a future patch which is forthcoming.

A greatful thanks to all reviewers including Eli Friedman, James Dennett,
and especially the two gracious wizards (Richard Smith and Doug Gregor)
who spent hours providing feedback (in person in Chicago and on the mailing lists).
And yet I am certain that I have allowed unidentified bugs to creep in; bugs, that I will do my best to slay, once identified!


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191453 91177308-0d34-0410-b5e6-96231b3b80d8
0c018357b8bbb1f96bbf622a5807421e626b4228 06-Sep-2013 Alexey Bataev <a.bataev@hotmail.com> OpenMP: Data-sharing attributes analysis and clause 'shared' (fixed test threadprivate_messages.cpp)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190183 91177308-0d34-0410-b5e6-96231b3b80d8
4367829b41e89d2f3dfae94a97af40ffa01c56c9 03-Sep-2013 Rafael Espindola <rafael.espindola@gmail.com> Revert "OpenMP: Data-sharing attributes analysis and clause 'shared'"

This reverts commit r189795.

threadprivate_messages.cpp is faling on windows.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189811 91177308-0d34-0410-b5e6-96231b3b80d8
8f1a2db8649eb151ee620273dcf34b700176430f 03-Sep-2013 Alexey Bataev <a.bataev@hotmail.com> OpenMP: Data-sharing attributes analysis and clause 'shared'

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189795 91177308-0d34-0410-b5e6-96231b3b80d8
152b4e4652baedfceba1cd8115515629225e713f 22-Aug-2013 Manuel Klimek <klimek@google.com> Revert "Implement a rudimentary form of generic lambdas."

This reverts commit 606f5d7a99b11957e057e4cd1f55f931f66a42c7.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189004 91177308-0d34-0410-b5e6-96231b3b80d8
ecb5819a9e64fb654d46a3b270a286cc570c58ff 22-Aug-2013 Faisal Vali <faisalv@yahoo.com> Implement a rudimentary form of generic lambdas.

Specifically, the following features are not included in this commit:
- any sort of capturing within generic lambdas
- nested lambdas
- conversion operator for captureless lambdas
- ensuring all visitors are generic lambda aware

As an example of what compiles:

template <class F1, class F2>
struct overload : F1, F2 {
using F1::operator();
using F2::operator();
overload(F1 f1, F2 f2) : F1(f1), F2(f2) { }

auto Recursive = [](auto Self, auto h, auto ... rest) {
return 1 + Self(Self, rest...);
auto Base = [](auto Self, auto h) {
return 1;
overload<decltype(Base), decltype(Recursive)> O(Base, Recursive);
int num_params = O(O, 5, 3, "abc", 3.14, 'a');

Please see attached tests for more examples.

Some implementation notes:

- Add a new Declarator context => LambdaExprParameterContext to
clang::Declarator to allow the use of 'auto' in declaring generic
lambda parameters

- Augment AutoType's constructor (similar to how variadic
template-type-parameters ala TemplateTypeParmDecl are implemented) to
accept an IsParameterPack to encode a generic lambda parameter pack.

- Add various helpers to CXXRecordDecl to facilitate identifying
and querying a closure class

- LambdaScopeInfo (which maintains the current lambda's Sema state)
was augmented to house the current depth of the template being
parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth)
so that Sema::ActOnLambdaAutoParameter may use it to create the
appropriate list of corresponding TemplateTypeParmDecl for each
auto parameter identified within the generic lambda (also stored
within the current LambdaScopeInfo). Additionally,
a TemplateParameterList data-member was added to hold the invented
TemplateParameterList AST node which will be much more useful
once we teach TreeTransform how to transform generic lambdas.

- SemaLambda.h was added to hold some common lambda utility
functions (this file is likely to grow ...)

- Teach Sema::ActOnStartOfFunctionDef to check whether it
is being called to instantiate a generic lambda's call
operator, and if so, push an appropriately prepared
LambdaScopeInfo object on the stack.

- Teach Sema::ActOnStartOfLambdaDefinition to set the
return type of a lambda without a trailing return type
to 'auto' in C++1y mode, and teach the return type
deduction machinery in SemaStmt.cpp to process either
C++11 and C++14 lambda's correctly depending on the flag.

- various tests were added - but much more will be needed.

A greatful thanks to all reviewers including Eli Friedman,
James Dennett and the ever illuminating Richard Smith. And
yet I am certain that I have allowed unidentified bugs to creep in;
bugs, that I will do my best to slay, once identified!


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188977 91177308-0d34-0410-b5e6-96231b3b80d8
f68af647dda5cca00b49be27d24f62b0a7fff986 10-Aug-2013 James Dennett <jdennett@google.com> Expose LambdaIntroducer::DefaultLoc in the AST's LambdaExpr.

Source-centric tools need access to the location of a C++11
lambda expression's capture-default ('&' or '=') when it's present.
It's possible for them to find it by re-lexing and re-implementing
rules that Clang's parser has already applied, but the cost of storing
the SourceLocation and making it available to them is 32 bits per
LambdaExpr (a small delta, proportionally), and the simplification in
client code is significant.

Reviewers: rsmith

Reviewed By: rsmith

CC: cfe-commits, klimek, revane

Differential Revision: http://llvm-reviews.chandlerc.com/D1192

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188121 91177308-0d34-0410-b5e6-96231b3b80d8
0d8e9646bc000bab521ce52ed294209a92298cef 16-May-2013 Richard Smith <richard-llvm@metafoo.co.uk> First pass of semantic analysis for init-captures: check the initializer, build
a FieldDecl from it, and propagate both into the closure type and the

You can't do much useful with them yet -- you can't use them within the body
of the lambda, because we don't have a representation for "the this of the
lambda, not the this of the enclosing context". We also don't have support or a
representation for a nested capture of an init-capture yet, which was intended
to work despite not being allowed by the current standard wording.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181985 91177308-0d34-0410-b5e6-96231b3b80d8
8c045ace381972f41d385b0a661ccf172834f459 03-May-2013 Ben Langmuir <ben.langmuir@intel.com> Move CapturedStmt parameters to CapturedDecl

Move the creation of CapturedStmt parameters out of CodeGen and into
Sema, making it easier to customize the outlined function. The
ImplicitParamDecls are stored in the CapturedDecl using an
ASTContext-allocated array.

Differential Revision: http://llvm-reviews.chandlerc.com/D722

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181043 91177308-0d34-0410-b5e6-96231b3b80d8
3a2f91280a49f4747063f983dc6a3296bd9359d2 29-Apr-2013 Ben Langmuir <ben.langmuir@intel.com> Small CapturedStmt improvements

Add a CapturedStmt.h similar to Lambda.h to reduce the typing required to get
to the CapturedRegionKind enum. This also allows codegen to access this enum
without including Sema/ScopeInfo.h.

Also removes some duplicated code for capturing 'this' between CapturedStmt and

Differential Revision: http://llvm-reviews.chandlerc.com/D712

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180710 91177308-0d34-0410-b5e6-96231b3b80d8
0579c165aa54840898956703ebd63bdd1f4dd907 18-Apr-2013 Benjamin Kramer <benny.kra@googlemail.com> Add llvm_unreachable at end of fully covered switch to pacify GCC.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179753 91177308-0d34-0410-b5e6-96231b3b80d8
6afcf8875d4e447645cd7bf3733dd8e2eb8455dc 16-Apr-2013 Tareq A. Siraj <tareq.a.sriaj@intel.com> Sema for Captured Statements

Add CapturedDecl to be the DeclContext for CapturedStmt, and perform semantic
analysis. Currently captures all variables by reference.

TODO: templates

Author: Ben Langmuir <ben.langmuir@intel.com>

Differential Revision: http://llvm-reviews.chandlerc.com/D433

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179618 91177308-0d34-0410-b5e6-96231b3b80d8
820b23dc924a4ae7af07d5a75d6b1d781c267d57 15-Feb-2013 Argyrios Kyrtzidis <akyrtzi@gmail.com> When a statement is dropped from the AST because it was invalid, make sure
we don't do the scope checks otherwise we are going to hit assertion checks
since a label may not have been actually added.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175281 91177308-0d34-0410-b5e6-96231b3b80d8
cfa88f893915ceb8ae4ce2f17c46c24a4d67502f 12-Jan-2013 Dmitri Gribenko <gribozavr@gmail.com> Remove useless 'llvm::' qualifier from names like StringRef and others that are
brought into 'clang' namespace by clang/Basic/LLVM.h

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172323 91177308-0d34-0410-b5e6-96231b3b80d8
c0e44454bd78b8b4f3d70f08cf1edd5466b0c798 29-Oct-2012 Jordan Rose <jordan_rose@apple.com> -Warc-repeated-use-of-weak: allow single reads in loops from local variables.

Previously, the warning would erroneously fire on this:

for (Test *a in someArray)

...because it looks like the same property is being accessed over and over.
However, clearly this is not the case. We now ignore loops like this for
local variables, but continue to warn if the base object is a parameter,
global variable, or instance variable, on the assumption that these are
not repeatedly usually assigned to within loops.

Additionally, do-while loops where the condition is 'false' are not really
loops at all; usually they're just used for semicolon-swallowing macros or
using "break" like "goto".


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166942 91177308-0d34-0410-b5e6-96231b3b80d8
c3f1742bdd1ae0091d51168e111cd63861587b13 25-Oct-2012 Douglas Gregor <dgregor@apple.com> When capturing 'this' in a lambda, make sure to update the set of
array-index starting values for the 'this' capture. Fixes

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166709 91177308-0d34-0410-b5e6-96231b3b80d8
535a5d001b2035a7aa68ee368fbe44ec90e33740 19-Oct-2012 Jordan Rose <jordan_rose@apple.com> Allow objc_requires_super to be used to check class methods as well.

Also, unify ObjCShouldCallSuperDealloc and ObjCShouldCallSuperFinalize.
The two have identical behavior and will never be active at the same time.

There's one last simplification now, which is that if we see a call to
[super foo] and we are currently in a method named 'foo', we will
/unconditionally/ clear the ObjCShouldCallSuper flag, rather than check
first to see if we're in a method where calling super is required. There's
no reason to pay the extra lookup price here.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166285 91177308-0d34-0410-b5e6-96231b3b80d8
b43d87b0646aa04951056c7e0d1ab9a58eb09f66 12-Oct-2012 Sean Silva <silvas@purdue.edu> Remove pointless classof()'s.

Updates to llvm/Support/Casting.h have rendered these classof()'s

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165770 91177308-0d34-0410-b5e6-96231b3b80d8
7fffce781e6ecbf4058b24df7e5ae3037569aa56 11-Oct-2012 Jordan Rose <jordan_rose@apple.com> -Warc-repeated-use-of-weak: Check messages to property accessors as well.

Previously, [foo weakProp] was not being treated the same as foo.weakProp.
Now, for every explicit message send, we check if it's a property access,
and if so, if the property is weak. Then for every assignment of a
message, we have to do the same thing again.

This is a potentially expensive increase because determining whether a
method is a property accessor requires searching through the methods it
overrides. However, without it -Warc-repeated-use-of-weak will miss cases
from people who prefer not to use dot syntax. If this turns out to be
too expensive, we can try caching the result somewhere, or even lose
precision by not checking superclass methods. The warning is off-by-default,


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165718 91177308-0d34-0410-b5e6-96231b3b80d8
b6d80fe68d30ebd14b20c96643c252c36041df8d 29-Sep-2012 Jordan Rose <jordan_rose@apple.com> Use a custom DenseMapInfo for WeakObjectProfileTy.

We can't specialize the usual llvm::DenseMapInfo at the end of the file
because by that point the DenseMap in FunctionScopeInfo has already been

No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164862 91177308-0d34-0410-b5e6-96231b3b80d8
a55d32d1b8f799bf58c02540983976368c42d895 29-Sep-2012 Jordan Rose <jordan_rose@apple.com> Pull ScopeInfo implementation into its own file.

The infrastructure for -Warc-repeated-use-of-weak got a little too heavy
to leave sitting at the top of Sema.cpp.

No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164856 91177308-0d34-0410-b5e6-96231b3b80d8
7a2704800943fbb69207e125d28186278712af36 29-Sep-2012 Jordan Rose <jordan_rose@apple.com> -Warc-repeated-use-of-weak: check ivars and variables as well.

Like properties, loading from a weak ivar twice in the same function can
give you inconsistent results if the object is deallocated between the
two loads. It is safer to assign to a strong local variable and use that.

Second half of <rdar://problem/12280249>.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164855 91177308-0d34-0410-b5e6-96231b3b80d8
58b6bdcdeb683a3504f2248a409e1f4e85876cee 29-Sep-2012 Jordan Rose <jordan_rose@apple.com> Add a warning (off by default) for repeated use of the same weak property.

The motivating example:

if (self.weakProp)

As with any non-atomic test-then-use, it is possible a weak property to be
non-nil at the 'if', but be deallocated by the time it is used. The correct
way to write this example is as follows:

id tmp = self.weakProp;
if (tmp)

The warning is controlled by -Warc-repeated-use-of-receiver, and uses the
property name and base to determine if the same property on the same object
is being accessed multiple times. In cases where the base is more
complicated than just a single Decl (e.g. 'foo.bar.weakProp'), it picks a
Decl for some degree of uniquing and reports the problem under a subflag,
-Warc-maybe-repeated-use-of-receiver. This gives a way to tune the
aggressiveness of the warning for a particular project.

The warning is not on by default because it is not flow-sensitive and thus
may have a higher-than-acceptable rate of false positives, though it is
less noisy than -Wreceiver-is-weak. On the other hand, it will not warn
about some cases that may be legitimate issues that -Wreceiver-is-weak
will catch, and it does not attempt to reason about methods returning weak

Even though this is not a real "analysis-based" check I've put the bug
emission code in AnalysisBasedWarnings for two reasons: (1) to run on
every kind of code body (function, method, block, or lambda), and (2) to
suggest that it may be enhanced by flow-sensitive analysis in the future.

The second (smaller) half of this work is to extend it to weak locals
and weak ivars. This should use most of the same infrastructure.

Part of <rdar://problem/12280249>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164854 91177308-0d34-0410-b5e6-96231b3b80d8
95aac15936e8362aeb4813f95bc255dee6473592 01-Aug-2012 Eli Friedman <eli.friedman@gmail.com> Fix an assertion failure instantiating a constexpr function from within a -dealloc method. PR13401.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161135 91177308-0d34-0410-b5e6-96231b3b80d8
612409ece080e814f79e06772c690d603f45fbd6 25-Jul-2012 Richard Smith <richard-llvm@metafoo.co.uk> PR12057: Allow variadic template pack expansions to cross lambda boundaries.
Rather than adding a ContainsUnexpandedParameterPack bit to essentially every
AST node, we tunnel the bit directly up to the surrounding lambda expression
when we reach a context where an unexpanded pack can not normally appear.
Thus any statement or declaration within a lambda can now potentially contain
an unexpanded parameter pack.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160705 91177308-0d34-0410-b5e6-96231b3b80d8
7dd900ed308506f9cf1cb72c70db1652f94cab37 02-Jul-2012 Jordan Rose <jordan_rose@apple.com> In blocks, only pretend that enum constants have enum type if necessary.

In C, enum constants have the type of the enum's underlying integer type,
rather than the type of the enum. (This is not true in C++.) Thus, when a
block's return type is inferred from an enum constant, it is incompatible
with expressions that return the enum type.

In r158899, I told block returns to pretend that enum constants have enum
type, like in C++. Doug Gregor pointed out that this can break existing code.

Now, we don't check the types of return statements until the end of the block.
This lets us go back and add implicit casts in blocks with mixed enum
constants and enum-typed expressions.

<rdar://problem/11662489> (again)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159591 91177308-0d34-0410-b5e6-96231b3b80d8
809d1be9820039b4cf6efa48246a0d70ffa13394 14-Jun-2012 James Dennett <jdennett@google.com> More doxygen/documentation cleanups.

This reduces the number of warnings generated by Doxygen by about 100
(roughly 10%). Issues addressed:
(1) Primarily, backslash-escaped "@foo" and "#bah" in Doxygen comments
when they're not supposed to be Doxygen commands or links, and
similarly for "<baz>" when it's not intended as as HTML tag;
(2) Changed some \t commands (which don't exist) to \c ("to refer to a
word of code", as the Doxygen manual says);
(3) \precondition becomes \pre;
(4) When touching comments, deleted a couple of spurious spaces in them;
(5) Changed some \n and \r to \\n and \\r;
(6) Fixed one tiny typo: #pragms -> #pragma.

This patch touches documentation/comments only.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158422 91177308-0d34-0410-b5e6-96231b3b80d8
999713eea940f4e087cc3ac878689c5c5c7a7225 18-Feb-2012 Douglas Gregor <dgregor@apple.com> Rewrite variable capture within lambda expressions and blocks,
eliminating a bunch of redundant code and properly modeling how the
captures of outside blocks/lambdas affect the types seen by inner

This new scheme makes two passes over the capturing scope stack. The
first pass goes up the stack (from innermost to outermost), assessing
whether the capture looks feasible and stopping when it either hits
the scope where the variable is declared or when it finds an existing
capture. The second pass then walks down the stack (from outermost to
innermost), capturing the variable at each step and updating the
captured type and the type that an expression referring to that
captured variable would see. It also checks type-specific
restrictions, such as the inability to capture an array within a
block. Note that only the first odr-use of each
variable needs to do the full walk; subsequent uses will find the
capture immediately, so multiple walks need not occur.

The same routine that builds the captures can also compute the type of
the captures without signaling errors and without actually performing
the capture. This functionality is used to determine the type of
declaration references as well as implementing the weird decltype((x))
rule within lambda expressions.

The capture code now explicitly takes sides in the debate over C++
core issue 1249, which concerns the type of captures within nested
lambdas. We opt to use the more permissive, more useful definition
implemented by GCC rather than the one implemented by EDG.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150875 91177308-0d34-0410-b5e6-96231b3b80d8
625bb569df0c34feec0d52c0ec5215f21ef2e054 14-Feb-2012 Dmitri Gribenko <gribozavr@gmail.com> Generalize -Wempty-body: warn when statement body is empty (closes: PR11329)

* if, switch, range-based for: warn if semicolon is on the same line.
* for, while: warn if semicolon is on the same line and either next
statement is compound statement or next statement has more

Replacing the semicolon with {} or moving the semicolon to the next
line will always silence the warning.

Tests from SemaCXX/if-empty-body.cpp merged into SemaCXX/warn-empty-body.cpp.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150515 91177308-0d34-0410-b5e6-96231b3b80d8
a73652465bcc4c0f6cb7d933ad84e002b527a643 14-Feb-2012 Douglas Gregor <dgregor@apple.com> Implement support for lambda capture pack expansions, e.g.,

[&values...] { print(values...); }

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150497 91177308-0d34-0410-b5e6-96231b3b80d8
9daa7bfdff7256cef693d7bf10084881bcb9253c 13-Feb-2012 Douglas Gregor <dgregor@apple.com> Keep track of the set of array index variables we use when we
synthesize a by-copy captured array in a lambda. This information will
be needed by IR generation.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150396 91177308-0d34-0410-b5e6-96231b3b80d8
f8af98286022f72157d84951b48fde5fb369ab29 12-Feb-2012 Douglas Gregor <dgregor@apple.com> Within the body of a lambda expression, decltype((x)) for an
id-expression 'x' will compute the type based on the assumption that
'x' will be captured, even if it isn't captured, per C++11
[expr.prim.lambda]p18. There are two related refactors that go into
implementing this:

1) Split out the check that determines whether we should capture a
particular variable reference, along with the computation of the
type of the field, from the actual act of capturing the
2) Always compute the result of decltype() within Sema, rather than
AST, because the decltype() computation is now context-sensitive.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150347 91177308-0d34-0410-b5e6-96231b3b80d8
668165ab1e604b063c0aa0df8ff91c80879670bf 11-Feb-2012 Eli Friedman <eli.friedman@gmail.com> Make sure Sema creates a field for 'this' captures. (Doug, please double-check that this is correct.)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150292 91177308-0d34-0410-b5e6-96231b3b80d8
503384f731b5abcbf870b0a5224eb920e631db0a 09-Feb-2012 Douglas Gregor <dgregor@apple.com> Various interrelated cleanups for lambdas:
- Complete the lambda class when we finish the lambda expression
(previously, it was left in the "being completed" state)
- Actually return the LambdaExpr object and bind to the resulting
temporary when needed.
- Detect when cleanups are needed while capturing a variable into a
lambda (e.g., due to default arguments in the copy constructor), and
make sure those cleanups apply for the whole of the lambda

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150123 91177308-0d34-0410-b5e6-96231b3b80d8
76e3da57b0e8cf72d221f44d54566ef206341668 08-Feb-2012 Douglas Gregor <dgregor@apple.com> When completing a lambda expression, make sure to check and attach the
body of the lambda to the function call operator.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150087 91177308-0d34-0410-b5e6-96231b3b80d8
01d08018b7cf5ce1601707cfd7a84d22015fc04e 07-Feb-2012 Douglas Gregor <dgregor@apple.com> Introduce basic ASTs for lambda expressions. This covers:
- Capturing variables by-reference and by-copy within a lambda
- The representation of lambda captures
- The creation of the non-static data members in the lambda class
that store the captured variables
- The initialization of the non-static data members from the
captured variables
- Pretty-printing lambda expressions

There are a number of FIXMEs, both explicit and implied, including:
- Creating a field for a capture of 'this'
- Improved diagnostics for initialization failures when capturing
variables by copy
- Dealing with temporaries created during said initialization
- Template instantiation
- AST (de-)serialization
- Binding and returning the lambda expression; turning it into a
proper temporary
- Lots and lots of semantic constraints
- Parameter pack captures

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149977 91177308-0d34-0410-b5e6-96231b3b80d8
b11a7fd2f2204c7aadd74f870c98667d461997f5 05-Feb-2012 Aaron Ballman <aaron@aaronballman.com> Fixing a warning in MSVC (this is also a test commit)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149806 91177308-0d34-0410-b5e6-96231b3b80d8
b942cb24a060435b18fef5b43eb33d77afc0d03a 03-Feb-2012 Eli Friedman <eli.friedman@gmail.com> Implement implicit capture for lambda expressions.

Still left: explicit captures in lambdas need to cause implicit capture, and I need to take a look at the diagnostics for some cases.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149718 91177308-0d34-0410-b5e6-96231b3b80d8
d67d0cc40f31956b40b44b6ee3619d17a0f73294 03-Feb-2012 Eli Friedman <eli.friedman@gmail.com> Note whether a lambda is mutable in the LambdaScopeInfo; this information will be necessary to handle references to captured variables.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149660 91177308-0d34-0410-b5e6-96231b3b80d8
a1f2114d9e81923c750f6b439302ac03552c37db 01-Feb-2012 Douglas Gregor <dgregor@apple.com> Introduce the lambda scope before determining explicit captures, which
cleans up and improves a few things:
- We get rid of the ugly dance of computing all of the captures in
data structures that clone those of CapturingScopeInfo, centralizing
the logic for accessing/updating these data structures
- We re-use the existing capture logic for 'this', which actually
works now.

Cleaned up some diagnostic wording in minor ways as well.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149516 91177308-0d34-0410-b5e6-96231b3b80d8
93962e5360a43200faa70939571afc4fb9326cf7 01-Feb-2012 Douglas Gregor <dgregor@apple.com> Improve checking of explicit captures in a C++11 lambda expression:
- Actually building the var -> capture mapping properly (there was an off-by-one error)
- Keeping track of the source location of each capture
- Minor QoI improvements, e.g, highlighing the prior capture if
there are multiple captures, pointing at the variable declaration we
found if we reject it.

As part of this, add standard citations for the various semantic
checks we perform, and note where we're not performing those checks as
we should.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149462 91177308-0d34-0410-b5e6-96231b3b80d8
84b007fae6c0cd30fa07074d34fbe2bf61fa44f9 26-Jan-2012 Eli Friedman <eli.friedman@gmail.com> Refactor to share code for handling return statements between lambda expressions and block literals. As it turns out, almost all the logic can be shared.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149031 91177308-0d34-0410-b5e6-96231b3b80d8
b69b42c55d56815bab62991bf839cdb41634d3af 11-Jan-2012 Eli Friedman <eli.friedman@gmail.com> Start refactoring code for capturing variables and 'this' so that it is shared between lambda expressions and block literals.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147917 91177308-0d34-0410-b5e6-96231b3b80d8
72899c34e3d1abfffa241ad0ce5c4bf175e5ea51 07-Jan-2012 Eli Friedman <eli.friedman@gmail.com> More lambda work: semantic analysis of capturing 'this'. It's a bit complicated, but we have to be careful about when exactly captures are marked given PotentiallyPotentiallyEvaluated contexts. (Actually, it's not 100% correct yet, but it's close enough for the moment.)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147723 91177308-0d34-0410-b5e6-96231b3b80d8
e81d7e9810eed0d805263791d761ec545d2cf779 07-Jan-2012 Eli Friedman <eli.friedman@gmail.com> Lambdas: semantic analysis of explicit captures.

This patch (and some of my other commits related to lambdas) is heavily based off of John Freeman's work-in-progress patches.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147706 91177308-0d34-0410-b5e6-96231b3b80d8
906a7e1c0f272f7e539c82dda01f4644031ce637 06-Jan-2012 Eli Friedman <eli.friedman@gmail.com> More lambda work. Fixes a minor bug Richard pointed out, makes lookup for lambda parameters work correctly, recording more information into the AST.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147650 91177308-0d34-0410-b5e6-96231b3b80d8
ec9ea7200718478e8a976529defbe21942a11c9c 05-Jan-2012 Eli Friedman <eli.friedman@gmail.com> More lambda work. Tweak the Sema interface slightly. Start adding the pieces to build the lambda class and its call operator. Create an actual scope for the lambda body.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147595 91177308-0d34-0410-b5e6-96231b3b80d8
d6471f7c1921c7802804ce3ff6fe9768310f72b9 26-Sep-2011 David Blaikie <dblaikie@gmail.com> Rename Diagnostic to DiagnosticsEngine as per issue 5397

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140478 91177308-0d34-0410-b5e6-96231b3b80d8
686775deca8b8685eb90801495880e3abdd844c2 20-Jul-2011 Chris Lattner <sabre@nondot.org> now that we have a centralized place to do so, add some using declarations for
some common llvm types: stringref and smallvector. This cleans up the codebase
quite a bit.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135576 91177308-0d34-0410-b5e6-96231b3b80d8
351ba91eaa6d30e523587b2d7ed676a5172c6e56 23-Feb-2011 Ted Kremenek <kremenek@apple.com> Enhance Sema::DiagRuntimeBehavior() to delay some diagnostics to see if the related code is reachable. This suppresses some
diagnostics that occur in unreachable code (e.g., -Warray-bound).

We only pay the cost of doing the reachability analysis when we issue one of these diagnostics.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126290 91177308-0d34-0410-b5e6-96231b3b80d8
337e550218128e7d922c09bb354fbc71de90c568 18-Feb-2011 Chris Lattner <sabre@nondot.org> Switch labels over to using normal name lookup, instead of their
own weird little DenseMap. Hey look, we now emit unused label
warnings deterministically, amazing.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125813 91177308-0d34-0410-b5e6-96231b3b80d8
e476bdce8cf3315c8ce852480503a8acc265bd54 18-Feb-2011 Chris Lattner <sabre@nondot.org> make block bodies handle undefined labels just like functions.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125799 91177308-0d34-0410-b5e6-96231b3b80d8
ad8dcf4a9df0e24051dc31bf9e6f3cd138a34298 17-Feb-2011 Chris Lattner <sabre@nondot.org> Step #1/N of implementing support for __label__: split labels into
LabelDecl and LabelStmt. There is a 1-1 correspondence between the
two, but this simplifies a bunch of code by itself. This is because
labels are the only place where we previously had references to random
other statements, causing grief for AST serialization and other stuff.

This does cause one regression (attr(unused) doesn't silence unused
label warnings) which I'll address next.

This does fix some minor bugs:
1. "The only valid attribute " diagnostic was capitalized.
2. Various diagnostics printed as ''labelname'' instead of 'labelname'
3. This reduces duplication of label checking between functions and blocks.

Review appreciated, particularly for the cindex and template bits.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125733 91177308-0d34-0410-b5e6-96231b3b80d8
6b5a61b6dc400027fd793dcadceeb9da944a37ea 07-Feb-2011 John McCall <rjmccall@apple.com> A few more tweaks to the blocks AST representation:
- BlockDeclRefExprs always store VarDecls
- BDREs no longer store copy expressions
- BlockDecls now store a list of captured variables, information about
how they're captured, and a copy expression if necessary

With that in hand, change IR generation to use the captures data in
blocks instead of walking the block independently.

Additionally, optimize block layout by emitting fields in descending
alignment order, with a heuristic for filling in words when alignment
of the end of the block header is insufficient for the most aligned

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125005 91177308-0d34-0410-b5e6-96231b3b80d8
469a1eb996e1cb0be54f9b210f836afbddcbb2cc 02-Feb-2011 John McCall <rjmccall@apple.com> An insomniac stab at making block declarations list the variables they close
on, as well as more reliably limiting invalid references to locals from
nested scopes.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@124721 91177308-0d34-0410-b5e6-96231b3b80d8
8fc32d272bd57b0a59f61c874cb7b56d9005e89e 19-Nov-2010 Argyrios Kyrtzidis <akyrtzi@gmail.com> Refactoring. Get FunctionScopeInfo to use DiagnosticErrorTrap.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119764 91177308-0d34-0410-b5e6-96231b3b80d8
781472fe99a120098c631b0cbe33c89f8cef5e70 25-Aug-2010 John McCall <rjmccall@apple.com> Split FunctionScopeInfo and BlockScopeInfo into their own header.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112038 91177308-0d34-0410-b5e6-96231b3b80d8