Commit Graph

6 Commits

Author SHA1 Message Date
Richard Smith 42b1057244 N3922: direct-list-initialization of an auto-typed variable no longer deduces a
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
2015-11-11 01:36:17 +00:00
James Dennett dd2ffea288 Replace the broken LambdaCapture::isInitCapture API.
A LambdaCapture does not have sufficient information
to correctly determine whether it is an init-capture or not.
Doing so requires knowledge held in the LambdaExpr itself.

It the case of a nested capture of an init-capture it is not
sufficient to check (as LambdaCapture::isInitCapture did)
whether the associated VarDecl was from an init-capture.

This patch moves isInitCapture to LambdaExpr and updates
Capture->isInitCapture() to Lambda->isInitCapture(Capture).

llvm-svn: 236760
2015-05-07 18:48:18 +00:00
Faisal Vali c9c5d1604f Move a generic lambda test into the more logical test file.
llvm-svn: 196723
2013-12-08 15:11:48 +00:00
Faisal Vali 5ab61b09be Fix an assertion introduced by my previous refactoring.
Add back the test that was triggering the assertion (which I removed mistakenly thinking it was triggering just a warning and not an assertion).  My error was brought to my attention by Rafael (Thanks!).

llvm-svn: 196721
2013-12-08 15:00:29 +00:00
Faisal Vali 5fb7c3c4ed Fix init-captures for generic lambdas.
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
2013-12-05 01:40:41 +00:00
Richard Smith 846f13ca14 Add extra testing for init-captures.
llvm-svn: 191608
2013-09-28 05:23:21 +00:00