This patch fixes an assertion that is triggered when RecordLayoutBuilder
tries to compute the size of a field (for capture "name" in the test
case) whose type hasn't been deduced. The patch fixes the bug by
correcting the typo of the capture initializer after the initializer is
parsed and before setting the expression for the annotation token.
Fixes PR30566.
rdar://problem/23380132
Differential Revision: https://reviews.llvm.org/D25206
llvm-svn: 290156
The code pattern used to implement the token rewriting hack doesn't
interact well with token caching in the pre-processor. As a result,
clang would crash on 'int f(::(id));' while doing a tenative parse of
the contents of the outer parentheses. The original code from PR11852
still doesn't crash the compiler.
This error recovery also often does the wrong thing with member function
pointers. The test case from the original PR doesn't recover the right
way either:
void S::(*pf)() = S::f; // should be 'void (S::*pf)()'
Instead we were recovering as 'void S::*pf()', which is still wrong.
If we still think that users mistakenly parenthesize identifiers in
nested name specifiers, we should change clang to intentionally parse
that form with an error, rather than doing a token rewrite.
Fixes PR26623, but I think there will be many more bugs like this around
token rewriting in the parser.
Reviewers: rsmith, rtrieu
Differential Revision: https://reviews.llvm.org/D25882
llvm-svn: 289273
This saves two pointers from FunctionDecl that were being used for some
rare and questionable C-only functionality. The DeclsInPrototypeScope
ArrayRef was added in r151712 in order to parse this kind of C code:
enum e {x, y};
int f(enum {y, x} n) {
return x; // should return 1, not 0
}
The challenge is that we parse 'int f(enum {y, x} n)' it its own
function prototype scope that gets popped before we build the
FunctionDecl for 'f'. The original change was doing two questionable
things:
1. Saving all tag decls introduced in prototype scope on a TU-global
Sema variable. This is problematic when you have cases like this, where
'x' and 'y' shouldn't be visible in 'f':
void f(void (*fp)(enum { x, y } e)) { /* no x */ }
This patch fixes that, so now 'f' can't see 'x', which is consistent
with GCC.
2. Storing the decls in FunctionDecl in ActOnFunctionDeclarator so that
they could be used in ActOnStartOfFunctionDef. This is just an
inefficient way to move information around. The AST lives forever, but
the list of non-parameter decls in prototype scope is short lived.
Moving these things to the Declarator solves both of these issues.
Reviewers: rsmith
Subscribers: jmolloy, cfe-commits
Differential Revision: https://reviews.llvm.org/D27279
llvm-svn: 289225
Summary:
This is probably the sane place for the attribute to go, but nvcc
specifically rejects it. Other GNU-style attributes are allowed in this
position (although judging from the warning it emits for
host/device/global, those attributes are applied to the lambda's
anonymous struct, not to the function itself).
It would be nice to have a FixIt message here, but doing so, or even
just getting the correct range for the attribute, including its '((' and
'))'s, is apparently Hard.
Reviewers: rnk
Subscribers: cfe-commits, tra
Differential Revision: https://reviews.llvm.org/D25115
llvm-svn: 282911
Summary: There's an overload that we can use to make this a bit cleaner.
Reviewers: rnk
Subscribers: cfe-commits, tra
Differential Revision: https://reviews.llvm.org/D25114
llvm-svn: 282910
Summary: This is ugh, but it makes us compatible with NVCC. Fixes bug 26341.
Reviewers: rnk
Subscribers: cfe-commits, tra
Differential Revision: https://reviews.llvm.org/D25103
llvm-svn: 282879
Functions of Sema that work with building of nested name specifiers have too
many parameters (BuildCXXNestedNameSpecifier already expects 10 arguments).
With this change the information about identifier and its context is packed
into a structure, which is then passes to the semantic functions.
llvm-svn: 277976
decomposition declarations.
There are a couple of things in the wording that seem strange here:
decomposition declarations are permitted at namespace scope (which we partially
support here) and they are permitted as the declaration in a template (which we
reject).
llvm-svn: 276492
No semantic analysis yet.
This is a pain to disambiguate correctly, because the parsing rules for the
declaration form of a condition and of an init-statement are quite different --
for a token sequence that looks like a declaration, we frequently need to
disambiguate all the way to the ')' or ';'.
We could do better here in some cases by stopping disambiguation once we've
decided whether we've got an expression or not (rather than keeping going until
we know whether it's an init-statement declaration or a condition declaration),
by unifying our parsing code for the two types of declaration and moving the
syntactic checks into Sema; if this has a measurable impact on parsing
performance, I'll look into that.
llvm-svn: 274169
-Wfor-loop-analysis warnings for a for-loop with a condition variable. In such
a case, the loop condition variable is modified on each iteration of the loop
by definition.
Original commit message:
Rearrange condition handling so that semantic checks on a condition variable
are performed before the other substatements of the construct are parsed,
rather than deferring them until the end. This allows better error recovery
from semantic errors in the condition, improves diagnostic order, and is a
prerequisite for C++17 constexpr if.
llvm-svn: 273600
are performed before the other substatements of the construct are parsed,
rather than deferring them until the end. This allows better error recovery
from semantic errors in the condition, improves diagnostic order, and is a
prerequisite for C++17 constexpr if.
llvm-svn: 273548
If a closing ')' isn't found for a macro instantiation inside a '[',
the next token is EOF, this leads to crashes if we try to look ahead of
that. This could be triggered whenever trying to parse lambdas or objs
message expressions.
Differential Revision: http://reviews.llvm.org/D20451
rdar://problem/25662647
llvm-svn: 271314
This patch corresponds to reviews:
http://reviews.llvm.org/D15120http://reviews.llvm.org/D19125
It adds support for the __float128 keyword, literals and target feature to
enable it. Based on the latter of the two aforementioned reviews, this feature
is enabled on Linux on i386/X86 as well as SystemZ.
This is also the second attempt in commiting this feature. The first attempt
did not enable it on required platforms which caused failures when compiling
type_traits with -std=gnu++11.
If you see failures with compiling this header on your platform after this
commit, it is likely that your platform needs to have this feature enabled.
llvm-svn: 268898
Since this patch provided support for the __float128 type but disabled it
on all platforms by default, some platforms can't compile type_traits with
-std=gnu++11 since there is a specialization with __float128.
This reverts the patch until D19125 is approved (i.e. we know which platforms
need this support enabled).
llvm-svn: 266460
This patch corresponds to review:
http://reviews.llvm.org/D15120
It adds support for the __float128 keyword, literals and a target feature to
enable it. This support is disabled by default on all targets and any target
that has support for this type is free to add it.
Based on feedback that I've received from target maintainers, this appears to
be the right thing for most targets. I have not heard from the maintainers of
X86 which I believe supports this type. I will subsequently investigate the
impact of enabling this on X86.
llvm-svn: 266186
Support the constexpr specifier on lambda expressions - and support its inference from the lambda call operator's body.
i.e.
auto L = [] () constexpr { return 5; };
static_assert(L() == 5); // OK
auto Implicit = [] (auto a) { return a; };
static_assert(Implicit(5) == 5);
We do not support evaluation of lambda's within constant expressions just yet.
Implementation Strategy:
- teach ParseLambdaExpressionAfterIntroducer to expect a constexpr specifier and mark the invented function call operator's declarator's decl-specifier with it; Have it emit fixits for multiple decl-specifiers (mutable or constexpr) in this location.
- for cases where constexpr is not explicitly specified, have buildLambdaExpr check whether the invented function call operator satisfies the requirements of a constexpr function, by calling CheckConstexprFunctionDecl/Body.
Much obliged to Richard Smith for his patience and his care, in ensuring the code is clang-worthy.
llvm-svn: 264513
Implement lambda capture of *this by copy.
For e.g.:
struct A {
int d = 10;
auto foo() { return [*this] (auto a) mutable { d+=a; return d; }; }
};
auto L = A{}.foo(); // A{}'s lifetime is gone.
// Below is still ok, because *this was captured by value.
assert(L(10) == 20);
assert(L(100) == 120);
If the capture was implicit, or [this] (i.e. *this was captured by reference), this code would be otherwise undefined.
Implementation Strategy:
- amend the parser to accept *this in the lambda introducer
- add a new king of capture LCK_StarThis
- teach Sema::CheckCXXThisCapture to handle by copy captures of the
enclosing object (i.e. *this)
- when CheckCXXThisCapture does capture by copy, the corresponding
initializer expression for the closure's data member
direct-initializes it thus making a copy of '*this'.
- in codegen, when assigning to CXXThisValue, if *this was captured by
copy, make sure it points to the corresponding field member, and
not, unlike when captured by reference, what the field member points
to.
- mark feature as implemented in svn
Much gratitude to Richard Smith for his carefully illuminating reviews!
llvm-svn: 263921
While this won't help fix things like the bug that r260219 addressed, it
seems like good tidy up to have anyway.
(it might be nice if "makeArrayRef" always produced a MutableArrayRef &
let it decay to an ArrayRef when needed - then I'd use that for the
MutableArrayRefs in this patch)
If we had std::dynarray I'd use that instead of unique_ptr+size_t,
ideally (but then it'd have to be threaded down through the Preprocessor
all the way - no idea how painful that would be)
llvm-svn: 260246
std::initializer_list<T> type. Instead, the list must contain a single element
and the type is deduced from that.
In Clang 3.7, we warned by default on all the cases that would change meaning
due to this change. In Clang 3.8, we will support only the new rules -- per
the request in N3922, this change is applied as a Defect Report against earlier
versions of the C++ standard.
This change is not entirely trivial, because for lambda init-captures we
previously did not track the difference between direct-list-initialization and
copy-list-initialization. The difference was not previously observable, because
the two forms of initialization always did the same thing (the elements of the
initializer list were always copy-initialized regardless of the initialization
style used for the init-capture).
llvm-svn: 252688
the "" and the suffix; that breaks names such as 'operator""if'. For symmetry,
also remove the space between the 'operator' and the '""'.
llvm-svn: 249641
Summary:
- Store the exception specification range's begin and end SourceLocation in DeclaratorChuck::FunctionTypeInfo. These SourceLocations can be used in a FixItHint Range.
- Add diagnostic; function concept having an exception specification.
Reviewers: hubert.reinterpretcast, fraggamuffin, faisalv, aaron.ballman, rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11789
llvm-svn: 246005
Teach C++'s tentative parsing to handle specializations of Objective-C
class types (e.g., NSArray<NSString *>) as well as Objective-C
protocol qualifiers (id<NSCopying>) by extending type-annotation
tokens to handle this case. As part of this, remove Objective-C
protocol qualifiers from the declaration specifiers, which never
really made sense: instead, provide Sema entry points to make them
part of the type annotation token. Among other things, this properly
diagnoses bogus types such as "<NSCopying> id" which should have been
written as "id <NSCopying>".
Implements template instantiation support for, e.g., NSArray<T>*
in C++. Note that parameterized classes are not templates in the C++
sense, so that cannot (for example) be used as a template argument for
a template template parameter. Part of rdar://problem/6294649.
llvm-svn: 241545
This patch implements the functionality specified by DR948.
The changes are two fold. First, the parser was modified
to allow 'constexpr's to appear in condition declarations
(which was a hard error before). Second, Sema was modified
to cleanup maybe odr-used declarations by way of a call to
'ActOnFinishFullExpr'. As 'constexpr's were not allowed in
condition declarations before the cleanup wasn't necessary
(such declarations were always odr-used).
This fixes PR22491.
Differential Revision: http://reviews.llvm.org/D8978
llvm-svn: 240707
ParsePostfixExpressionSuffix() for '->' (or '.') postfixes first calls
ActOnStartCXXMemberReference() to inform sema that a member reference is about
to start, and that function lets the parser know if sema thinks that the
base expression's type could allow a pseudo destructor from a semantic point of
view (for example, if the the base expression has a dependent type).
ParsePostfixExpressionSuffix() then calls ParseOptionalCXXScopeSpecifier() and
passes MayBePseudoDestructor on to that function, expecting the function to
set it to false if a pseudo destructor is impossible from a syntactic point of
view (due to a lack of '~' sigil). However, ParseOptionalCXXScopeSpecifier()
had early-outs for ::new and __super, so MayBePseudoDestructor stayed true,
so we tried to parse a pseudo dtor, and then became confused since we couldn't
find a '~'. Move the snippet in ParseOptionalCXXScopeSpecifier() that sets
MayBePseudoDestructor to false above the early exits.
Parts of this found by SLi's bot.
llvm-svn: 229449
(or of a lambda init-capture, which is sort-of such a variable). The semantics
of such constructs will change when we implement N3922, so we intend to warn on
this in Clang 3.6 then change the semantics in Clang 3.7.
llvm-svn: 228792
This used to crash, complaining "ObjectType and scope specifier cannot coexist":
struct A { } b = b.~A::A <int>;
The only other caller of ParseOptionalCXXScopeSpecifier() that passes in a
non-empty ObjectType clears the ObjectType of the scope specifier comes back
non-empty (see the tok::period case in Parser::ParsePostfixExpressionSuffix()),
so do that here too.
Found by SLi's bot.
llvm-svn: 227781
Even with r227555, this still crashed:
struct S {
int A;
~A::A() {}
};
That's because ParseOptionalCXXScopeSpecifier()'s call to
ActOnCXXNestedNameSpecifier() doesn't mark the scope spec as invalid if sema
thought it's a good idea to fixit-correct "::" to ":". For the diagnostic
improvement done in r217302, we never want :: to be interpreted as :, so fix
this by setting ColonSacred to false temporarily.
Found by SLi's bot.
llvm-svn: 227581
The improved completion in call context now works with:
- Functions.
- Member functions.
- Constructors.
- New expressions.
- Function call expressions.
- Template variants of the previous.
There are still rough edges to be fixed:
- Provide support for optional parameters. (fix known)
- Provide support for member initializers. (fix known)
- Provide support for variadic template functions. (fix unknown)
- Others?
llvm-svn: 226670
Recovery from malformed lambda introducers would find us consuming the
synthetic default argument token, which is bad. Instead, stop right
before that token.
llvm-svn: 225613
Sema::CheckParmsForFunctionDef can't cope with a null TypeSourceInfo.
Don't let the AST contain the malformed lambda.
This fixes PR22122.
llvm-svn: 225505
Sema::ActOnIdExpression to use the new functionality.
Among other things, this allows recovery in several cases where it
wasn't possible before (e.g. correcting a mistyped static_cast<>).
llvm-svn: 222464
Clang supports __restrict__ as a function qualifier, but
DeclaratorChunk::FunctionTypeInfo lacked a field to track the qualifier's
source location (as we do with volatile, etc.). This was the subject of a FIXME
in GetFullTypeForDeclarator (in SemaType.cpp). This should also prove useful as
we add more warnings regarding questionable uses of the restrict qualifier.
There is no significant functional change (except for an improved source range
associated with the err_invalid_qualified_function_type diagnostic fixit
generated by GetFullTypeForDeclarator).
llvm-svn: 220215
We build a NestedNameSpecifier that records the CXXRecordDecl in which
__super appeared. Name lookup is performed in all base classes of the
recorded CXXRecordDecl. Use of __super is allowed only inside class and
member function scope.
llvm-svn: 218484
These calls to ConsumeCodeCompletionToken() caused parsing to continue
needlessly when an immediate cutOffParsing() would do.
Document the function to clarify its correct usage.
llvm-svn: 207823
Parse of nested name spacifier is modified so that it properly recovers
if colon is mistyped as double colon in case statement.
This patch fixes PR15133.
Differential Revision: http://llvm-reviews.chandlerc.com/D2870
llvm-svn: 206135
a missing include from CLog.h.
CLog.h referenced most of the core libclang types but never directly
included Index.h that provides them. Previously it got lucky and other
headers were always included first but with the sorting it ended up
first in one case and stopped compiling. Adding the Index.h include
fixes it right up.
llvm-svn: 202810
encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.
llvm-svn: 198686
This backs out changes in commit r198605 and part of r198604, replacing the
original tok::kw_template with a slightly more obvious placeholder
tok::unknown.
llvm-svn: 198666
Remove UnaryTypeTraitExpr and switch all remaining type trait related handling
over to TypeTraitExpr.
The UTT/BTT/TT enum prefix and evaluation code is retained pending further
cleanup.
This is part of the ongoing work to unify type traits following the removal of
BinaryTypeTraitExpr in r197273.
llvm-svn: 198271
1) Teach ExpectAndConsume() to emit expected and expected-after diagnostics
using the generic diagnostic descriptions added in r197972, eliminating another
set of trivial err_expected_* variations while maintaining existing behaviour.
2) Lift SkipUntil() recovery out of ExpectAndConsume(). The Expect/Consume
family of functions are primitive parser operations that now have the
well-defined property of operating on single tokens. Factoring out recovery
exposes opportunities for more consistent and tailored error recover at the
call sites instead of just relying on a bottled SkipUntil formula.
llvm-svn: 198270
Introduce proper facilities to render token spellings using the diagnostic
formatter.
Replaces most of the hard-coded diagnostic messages related to expected tokens,
which all shared the same semantics but had to be multiply defined due to
variations in token order or quote marks.
The associated parser changes are largely mechanical but they expose
commonality in whole chunks of the parser that can now be factored away.
This commit uses C++11 typed enums along with a speculative legacy fallback
until the transition is complete.
Requires corresponding changes in LLVM r197895.
llvm-svn: 197972
1) Introduce TryConsumeToken() to handle the common test-and-consume pattern.
This brings about readability improvements in the parser and optimizes to avoid
redundant checks in the common case.
2) Eliminate the ConsumeCodeCompletionTok special case from ConsumeToken(). This
was used by only one caller which has been switched over to the more
appropriate ConsumeCodeCompletionToken() function.
llvm-svn: 197497
There's nothing special about type traits accepting two arguments.
This commit eliminates BinaryTypeTraitExpr and switches all related handling
over to TypeTraitExpr.
Also fixes a CodeGen failure with variadic type traits appearing in a
non-constant expression.
The BTT/TT prefix and evaluation code is retained as-is for now but will soon
be further cleaned up.
This is part of the ongoing work to unify type traits.
llvm-svn: 197273
Type trait parsing is all over the place at the moment with unary, binary and
n-ary C++11 type traits that were developed independently at different points
in clang's history.
There's no good reason to handle them separately -- there are three parsers,
three AST nodes and lots of duplicated handling code with slightly different
implementations and diags for each kind.
This commit unifies parsing of type traits and sets the stage for further
consolidation.
No change in behaviour other than more consistent error recovery.
llvm-svn: 197179
For an init capture, process the initialization expression
right away. For lambda init-captures such as the following:
const int x = 10;
auto L = [i = x+1](int a) {
return [j = x+2,
&k = x](char b) { };
};
keep in mind that each lambda init-capture has to have:
- its initialization expression executed in the context
of the enclosing/parent decl-context.
- but the variable itself has to be 'injected' into the
decl-context of its lambda's call-operator (which has
not yet been created).
Each init-expression is a full-expression that has to get
Sema-analyzed (for capturing etc.) before its lambda's
call-operator's decl-context, scope & scopeinfo are pushed on their
respective stacks. Thus if any variable is odr-used in the init-capture
it will correctly get captured in the enclosing lambda, if one exists.
The init-variables above are created later once the lambdascope and
call-operators decl-context is pushed onto its respective stack.
Since the lambda init-capture's initializer expression occurs in the
context of the enclosing function or lambda, therefore we can not wait
till a lambda scope has been pushed on before deciding whether the
variable needs to be captured. We also need to process all
lvalue-to-rvalue conversions and discarded-value conversions,
so that we can avoid capturing certain constant variables.
For e.g.,
void test() {
const int x = 10;
auto L = [&z = x](char a) { <-- don't capture by the current lambda
return [y = x](int i) { <-- don't capture by enclosing lambda
return y;
}
};
If x was not const, the second use would require 'L' to capture, and
that would be an error.
Make sure TranformLambdaExpr is also aware of this.
Patch approved by Richard (Thanks!!)
http://llvm-reviews.chandlerc.com/D2092
llvm-svn: 196454
nested-name-specifier, rather than crashing. (In fact, reject all
literal-operator-ids that have a non-namespace nested-name-specifier). The
grammar doesn't allow these in some cases, and in other cases does allow them
but instantiation will always fail.
llvm-svn: 196443
Summary: Some MS headers use these features.
Reviewers: rnk, rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1948
llvm-svn: 192936
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!
Thanks!
llvm-svn: 191453
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!
Thanks!
llvm-svn: 188977
