Remove code that tries to avoid transforming non-dependent call operator types
for lambda expressions. That can't ever work; we need to transform the
parameters in order to create new ones in the new

Remove code that tries to avoid transforming non-dependent call operator types
for lambda expressions. That can't ever work; we need to transform the
parameters in order to create new ones in the new call operator context.

Fixes a rejects-valid when transforming a context containing a
lambda-expression that uses its function parameters in C++14 mode.

llvm-svn: 222482

show more ...

Move test from r222476 to a better place; this was reduced to the point that it
no longer contained a generic lambda.

llvm-svn: 222477

Don't allow lambdas to capture invalid decls during template instantiations.

Fixes PR20731.

llvm-svn: 216936

PR19249: Don't forget to DiagnoseUseOfDecl for the implicit use of a variable
in a lambda capture.

llvm-svn: 204757

Temporary fix for PR18473: Don't try to evaluate the initializer for a
type-dependent variable, even if the initializer isn't value-dependent. This
happens for ParenListExprs composed of non-value-de

Temporary fix for PR18473: Don't try to evaluate the initializer for a
type-dependent variable, even if the initializer isn't value-dependent. This
happens for ParenListExprs composed of non-value-dependent subexpressions, for
instance.

We should really give ParenListExprs (and InitListExprs) the type of the
initialized entity if they're used to represent a dependent initialization (and
if so, set them to be type-, value- and instantiation-dependent).

llvm-svn: 200954

show more ...

PR18128: a lambda capture-default is not permitted for a non-local lambda
expression.

llvm-svn: 200948

Fix regression in r197623: only diagnose a by-copy capture of an incomplete
type if the capture is, actually, by copy.

llvm-svn: 199772

PR18477: Create a function scope representing the constructor call when
handling C++11 default initializers. Without this, other parts of Sema (such as
lambda capture) would think the default initial

PR18477: Create a function scope representing the constructor call when
handling C++11 default initializers. Without this, other parts of Sema (such as
lambda capture) would think the default initializer is part of the surrounding
function scope.

llvm-svn: 199453

show more ...

Fix computation of linkage within nested lambdas.

When nested C++11 lambdas are used in NSDMI's - this patch prevents infinite recursion by computing the linkage of any nested lambda by determining

Fix computation of linkage within nested lambdas.

When nested C++11 lambdas are used in NSDMI's - this patch prevents infinite recursion by computing the linkage of any nested lambda by determining the linkage of the outermost enclosing lambda (which might inherit its linkage from its parent).

See http://llvm-reviews.chandlerc.com/D1783 for Doug's approval.

[On a related note, I need this patch so as to pass tests of transformations of nested lambdas returned from member functions]

llvm-svn: 191727

show more ...

Revert the linkage fix.
I got a bunch of buildbot failures that i don't understand - sorry.

llvm-svn: 191647

Fix computation of linkage within nested lambdas.
When nested lambdas are used in NSDMI's - this prevents infinite recursion.

See http://llvm-reviews.chandlerc.com/D1783 for Doug's approval regardi

Fix computation of linkage within nested lambdas.
When nested lambdas are used in NSDMI's - this prevents infinite recursion.

See http://llvm-reviews.chandlerc.com/D1783 for Doug's approval regarding the code, and then request for some tests.

[On a related note, I need this patch so as to pass tests of transformations of nested lambdas returned from member functions]

llvm-svn: 191645

show more ...

Handle a difference in lambda return type deduction between C++11 and C++1y: if
no return type is specified, C++11 will deduce a cv-qualified return type in
some cases, but C++1y never will.

llvm-sv

Handle a difference in lambda return type deduction between C++11 and C++1y: if
no return type is specified, C++11 will deduce a cv-qualified return type in
some cases, but C++1y never will.

llvm-svn: 187275

show more ...

PR16708: If a lambda has an implicit return type, don't get confused if its return type has already been determined to be a type containing an 'auto'.

llvm-svn: 187266

Implement core issue 903: only integer literals with value 0 and prvalues of
type std::nullptr_t are null pointer constants from C++11 onwards.

llvm-svn: 183883

Sema: Don't emit a warning when __func__ is used in a lambda outside of a function.

Fixes PR14518.

llvm-svn: 169510

Update regression tests for r166617.

llvm-svn: 166619

DR1472: A reference isn't odr-used if it has preceding initialization,
initialized by a reference constant expression.

Our odr-use modeling still needs work here: we don't yet implement the 'set of

DR1472: A reference isn't odr-used if it has preceding initialization,
initialized by a reference constant expression.

Our odr-use modeling still needs work here: we don't yet implement the 'set of
potential results of an expression' DR.

llvm-svn: 166361

show more ...

Handle lambdas where the lambda-declarator is an explicit "(void)". PR13854.

llvm-svn: 164274

Add an extra check for invalid decls in the lambda semantic analysis to avoid a crash. PR13860.

llvm-svn: 164168

Implement warning for integral null pointer constants other than the literal 0.

This is effectively a warning for code that violates core issue 903 & thus will
become standard error in the future, h

Implement warning for integral null pointer constants other than the literal 0.

This is effectively a warning for code that violates core issue 903 & thus will
become standard error in the future, hopefully. It catches strange null
pointers such as: '\0', 1 - 1, const int null = 0; etc...

There's currently a flaw in this warning (& the warning for 'false' as a null
pointer literal as well) where it doesn't trigger on comparisons (ptr == '\0'
for example). Fix to come in a future patch.

Also, due to this only being a warning, not an error, it triggers quite
frequently on gtest code which tests expressions for null-pointer-ness in a
SFINAE context (so it wouldn't be a problem if this was an error as in an
actual implementation of core issue 903). To workaround this for now, the
diagnostic does not fire in unevaluated contexts.

Review by Sean Silva and Richard Smith.

llvm-svn: 161501

show more ...

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 t

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.

llvm-svn: 160705

show more ...

Fixes some test cases that should have come along with r157943.

llvm-svn: 157947

Make the error about assigning to lambda-captured variables
clearer, and mention the existence of mutable lambdas.

llvm-svn: 152598

Alternate fix to PR12248: put Sema in charge of special-casing
the diagnostic for assigning to a copied block capture. This has
the pleasant side-effect of letting us special-case the diagnostic
fo

Alternate fix to PR12248: put Sema in charge of special-casing
the diagnostic for assigning to a copied block capture. This has
the pleasant side-effect of letting us special-case the diagnostic
for assigning to a copied lambda capture as well, without introducing
a new non-modifiable enumerator for it.

llvm-svn: 152593

show more ...

Make sure we treat variables captured by reference in lambda as modifiable lvalues. Regression from r152491. Fixes PR12248.

llvm-svn: 152573