Commit Graph

53 Commits

Author SHA1 Message Date
Faisal Vali 56f1de4dcb Fix PR25627: constant expressions being odr-used in template arguments.
This patch ensures that clang processes the expression-nodes that are generated when disambiguating between types and expressions within template arguments as constant-expressions by installing the ConstantEvaluated ExpressionEvaluationContext just before attempting the disambiguation - and then making sure that Context carries through into ParseConstantExpression (by refactoring it out into a function that does not create its own EvaluationContext: ParseConstantExpressionInExprEvalContext) 

Note, prior to this patch, trunk would correctly disambiguate and identify the expression as an expression - and while it would annotate the token with the expression - it would fail to complete the odr-use processing (specifically, failing to trigger Sema::UpdateMarkingForLValueToRValue as is done for all Constant Expressions, which would remove it from being considered odr-used).  By installing the ConstantExpression Evaluation Context prior to disambiguation, and making sure it carries though, we ensure correct processing of the expression-node.

For e.g:
  template<int> struct X { };
  void f() {
    const int N = 10;
    X<N> x; // should be OK.
    [] { return X<N>{}; }; // Should be OK - no capture - but clang errors!
  }

See a related bug: https://bugs.llvm.org//show_bug.cgi?id=25627

In summary (and reiteration), the fix is as follows:

    - Remove the EnteredConstantEvaluatedContext action from ParseTemplateArgumentList (relying on ParseTemplateArgument getting it right)
    - Add the EnteredConstantEvaluatedContext action just prior to undergoing the disambiguating parse, and if the parse succeeds for an expression, carry the context though into a refactored version of ParseConstantExpression that does not create its own ExpressionEvaluationContext.

See https://reviews.llvm.org/D31588 for additional context regarding some of the more fragile and complicated approaches attempted, and Richard's feedback that eventually shaped the simpler and more robust rendition that is being committed.

Thanks Richard!

llvm-svn: 303492
2017-05-20 19:58:04 +00:00
Akira Hatanaka 51e60f9aeb [Parser] Correct typo after lambda capture initializer is parsed.
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
2016-12-20 02:11:29 +00:00
Richard Smith ca18579766 PR23281: Fix implementation of DR1891 to implement the intent: that is, a
lambda-expression does not have a move-assignment operator.

llvm-svn: 287057
2016-11-16 00:03:24 +00:00
Erik Pilkington 3cdc317342 [Sema] Teach getCurrentThisType to reconize lambda in in-class initializer
Fixes PR27994, a crash on valid.

Differential revision: https://reviews.llvm.org/D21145

llvm-svn: 276900
2016-07-27 18:25:10 +00:00
Richard Trieu 2334a30e15 Add null check to diagnostic path for lambda captures.
Previously, the failed capture of a variable in nested lambdas may crash when
the lambda pointer is null.  Only give the note if a location can be retreived
from the lambda pointer.

llvm-svn: 262765
2016-03-05 04:04:57 +00:00
Argyrios Kyrtzidis b4030df780 [SemaCXX] Fix crash-on-invalid while trying to deduce return type of a lambda.
rdar://22032373

llvm-svn: 259287
2016-01-30 01:51:20 +00:00
Serge Pavlov d9c0bcfd28 Classes inside lambdas are local not nested.
If a lambda used as default argument in a method declaration contained
a local class, that class was incorrectly recognized as nested class.
In this case compiler tried to postpone parsing of this class until
the enclosing class is finished, which caused crashes in some cases.

This change fixes PR13987.

Differential Revision: http://reviews.llvm.org/D11006

llvm-svn: 242132
2015-07-14 10:02:10 +00:00
Richard Smith 8c37ab5ffd PR21857: weaken an incorrect assertion.
llvm-svn: 228785
2015-02-11 01:48:47 +00:00
Richard Smith 5a0e50cd87 DR1048: drop top-level cv-qualifiers when deducing the return type of a
lambda-expression in C++11, to match the C++14 rules.

llvm-svn: 224620
2014-12-19 22:10:51 +00:00
Reid Kleckner aac43c6a77 Handle errors in lambda prototype instantiation correctly
Previously we would attempt to build a TypeSourceInfo for a null type,
and then we would forget to pop the function scope before returning an
error.

Reviewers: rsmith

Differential Revision: http://reviews.llvm.org/D6665

llvm-svn: 224271
2014-12-15 21:07:16 +00:00
Richard Smith 01014cee76 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
2014-11-20 23:53:14 +00:00
Richard Smith 4764e9bf79 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
2014-11-20 23:00:25 +00:00
Richard Trieu b292604553 Don't allow lambdas to capture invalid decls during template instantiations.
Fixes PR20731.

llvm-svn: 216936
2014-09-02 19:32:44 +00:00
Richard Smith d7b2a9ebd1 PR19249: Don't forget to DiagnoseUseOfDecl for the implicit use of a variable
in a lambda capture.

llvm-svn: 204757
2014-03-25 21:11:32 +00:00
Richard Smith c941ba9047 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
2014-02-06 23:35:16 +00:00
Richard Smith 3d584b0ced PR18128: a lambda capture-default is not permitted for a non-local lambda
expression.

llvm-svn: 200948
2014-02-06 21:49:08 +00:00
Richard Smith 111d3485af Fix regression in r197623: only diagnose a by-copy capture of an incomplete
type if the capture is, actually, by copy.

llvm-svn: 199772
2014-01-21 23:27:46 +00:00
Richard Smith 741081708e 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
2014-01-17 03:11:34 +00:00
Faisal Vali 49b4c1f0c8 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
2013-10-01 02:51:53 +00:00
Faisal Vali 98b8e18379 Revert the linkage fix.
I got a bunch of buildbot failures that i don't understand - sorry.

llvm-svn: 191647
2013-09-29 20:27:06 +00:00
Faisal Vali db29268b10 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
2013-09-29 20:00:15 +00:00
Richard Smith 1836e60023 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
2013-07-26 23:45:07 +00:00
Richard Smith fff926670b 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
2013-07-26 22:53:54 +00:00
Richard Smith 4055de40ab 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
2013-06-13 02:46:14 +00:00
Benjamin Kramer 6928cf7826 Sema: Don't emit a warning when __func__ is used in a lambda outside of a function.
Fixes PR14518.

llvm-svn: 169510
2012-12-06 15:42:21 +00:00
Eli Friedman be20d43232 Update regression tests for r166617.
llvm-svn: 166619
2012-10-24 20:28:18 +00:00
Richard Smith 5a1104bd3a 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
2012-10-20 01:38:33 +00:00
Eli Friedman 8f5e983029 Handle lambdas where the lambda-declarator is an explicit "(void)". PR13854.
llvm-svn: 164274
2012-09-20 01:40:23 +00:00
Eli Friedman e979db1583 Add an extra check for invalid decls in the lambda semantic analysis to avoid a crash. PR13860.
llvm-svn: 164168
2012-09-18 21:11:30 +00:00
David Blaikie 1c7c8f7637 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
2012-08-08 17:33:31 +00:00
Richard Smith 2589b9808e 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
2012-07-25 03:56:55 +00:00
Aaron Ballman 8d4688718b Fixes some test cases that should have come along with r157943.
llvm-svn: 157947
2012-06-04 20:07:46 +00:00
John McCall 46591a43af Make the error about assigning to lambda-captured variables
clearer, and mention the existence of mutable lambdas.

llvm-svn: 152598
2012-03-13 01:10:51 +00:00
John McCall 5fa2ef4445 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
2012-03-13 00:37:01 +00:00
Eli Friedman 60226ea0d7 Make sure we treat variables captured by reference in lambda as modifiable lvalues. Regression from r152491. Fixes PR12248.
llvm-svn: 152573
2012-03-12 20:57:19 +00:00
Richard Smith 35ecb36fcd Ensure that we instantiate static reference data members of class templates
early, since their values can be used in constant expressions in C++11. For
odr-use checking, the opposite change is required, since references are
odr-used whether or not they satisfy the requirements for appearing in a
constant expression.

llvm-svn: 151881
2012-03-02 04:14:40 +00:00
Richard Smith 5e1148e31d Remove FIXME: as Eli points out, the behavior here is now correct.
llvm-svn: 151405
2012-02-24 23:21:24 +00:00
Richard Smith 6365c9138e When checking whether a reference to a variable is an ICE, look at the type of
the declaration, not at the type of the DeclRefExpr, since within a lambda the
DeclRefExpr can be more const than the declaration is.

llvm-svn: 151399
2012-02-24 22:12:32 +00:00
Douglas Gregor 5dbc14f47e Only pop the expression evaluation context corresponding to a lambda
expression after we've finished the function body of the corresponding
function call operator. Otherwise, ActOnFinishFunctionBody() will see
the (unfinished) evaluation context of the lambda expression
itself. Fixes PR12031.

llvm-svn: 151082
2012-02-21 20:05:31 +00:00
Douglas Gregor fdf598eaf3 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
captures.

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.

llvm-svn: 150875
2012-02-18 09:37:24 +00:00
Douglas Gregor 81495f341d 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
  variable. 
  2) Always compute the result of decltype() within Sema, rather than
  AST, because the decltype() computation is now context-sensitive.

llvm-svn: 150347
2012-02-12 18:42:33 +00:00
Douglas Gregor 7345626a5b Implement return type deduction for lambdas per C++11
[expr.prim.lambda]p4, including the current suggested resolution of
core isue 975, which allows multiple return statements so long as the
types match. ExtWarn when user code is actually making use of this
extension.

llvm-svn: 150168
2012-02-09 10:18:50 +00:00
Douglas Gregor 656bc62a73 Remove the "unsupported" error for lambda expressions. It's annoying,
and rapidly becoming untrue.

llvm-svn: 150165
2012-02-09 08:26:42 +00:00
Douglas Gregor 8c50e7c5e3 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
  expression.
    

llvm-svn: 150123
2012-02-09 00:47:04 +00:00
Eli Friedman 8f66cdffa0 Fix the result of VarDecl::checkInitIsICE so it is consistently accurate in C++11 mode. PR11928.
llvm-svn: 149908
2012-02-06 21:50:18 +00:00
Eli Friedman a023e0c619 Make explicit captures which cause implicit captures work correctly.
llvm-svn: 149719
2012-02-03 23:06:43 +00:00
Eli Friedman 24af850470 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.

llvm-svn: 149718
2012-02-03 22:47:37 +00:00
Douglas Gregor cdd11d4e7e 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.

llvm-svn: 149516
2012-02-01 17:04:21 +00:00
Douglas Gregor 53a9bdf17e 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.

llvm-svn: 149462
2012-02-01 01:18:43 +00:00
Eli Friedman f49643ddce Add an additional testcase for a lambda with implicit void return type.
llvm-svn: 149034
2012-01-26 03:16:41 +00:00