copy constructors of classes with array members, instead using
ArrayInitLoopExpr to represent the initialization loop.
This exposed a bug in the static analyzer where it was unable to differentiate
between zero-initialized and unknown array values, which has also been fixed
here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289618 91177308-0d34-0410-b5e6-96231b3b80d8
Reworked fix after comments from Richard Smith. We must skip all
CapturedDecl-based contexts when trying to get correct mangling number
context.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286953 91177308-0d34-0410-b5e6-96231b3b80d8
Clang emits error message for the following code:
```
template <class F> void parallel_loop(F &&f) { f(0); }
int main() {
int x;
parallel_loop([&](auto y) {
{
x = y;
};
});
}
```
$ clang++ --std=gnu++14 clang_test.cc -o clang_test
clang_test.cc:9:7: error: reference to local variable 'x' declared in enclosing function 'main'
x = y;
^
clang_test.cc:2:48: note: in instantiation of function template specialization 'main()::(anonymous class)::operator()<int>' requested here
template <class F> void parallel_loop(F &&f) { f(0); }
^
clang_test.cc:6:3: note: in instantiation of function template specialization 'parallel_loop<(lambda at clang_test.cc:6:17)>' requested here parallel_loop([&](auto y) {
^
clang_test.cc:5:7: note: 'x' declared here
int x;
^
1 error generated.
Patch fixes this issue.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286584 91177308-0d34-0410-b5e6-96231b3b80d8
aren't captured by lambdas with a default capture specifier
This commit is a follow-up to r286354. It avoids the -Wshadow warning for
variables which shadow variables that aren't captured by lambdas with a default
capture specifier. It provides an additional note that points to location of
the capture.
The old behaviour is preserved with -Wshadow-all or -Wshadow-uncaptured-local.
rdar://14984176
Differential Revision: https://reviews.llvm.org/D26448
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286465 91177308-0d34-0410-b5e6-96231b3b80d8
There was a bug in the implementation of captured statements. If it has
a lambda expression in it and the same lambda expression is used outside
the captured region, clang produced an error:
```
error: definition with same mangled name as another definition
```
Here is an example:
```
struct A {
template <typename L>
void g(const L&) { }
};
template<typename T>
void f() {
{
A().g([](){});
}
A().g([](){});
}
int main() {
f<void>();
}
```
Error report:
```
main.cpp:3:10: error: definition with same mangled name as another
definition
void g(const L&) { }
^
main.cpp:3:10: note: previous definition is here
```
Patch fixes this bug.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284229 91177308-0d34-0410-b5e6-96231b3b80d8
I'm told that some optimizers like lambdas a lot more than mem_fn.
Given that the readability difference is basically nil, and we seem to
use lambdas basically everywhere else, it seems sensible to just use
lambdas.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276577 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Space for storing the //constraint-expression// of the
//requires-clause// associated with a `TemplateParameterList` is
arranged by taking a bit out of the `NumParams` field for the purpose
of determining whether there is a //requires-clause// or not, and by
adding to the trailing objects tied to the `TemplateParameterList`. An
accessor is provided.
An appropriate argument is supplied to `TemplateParameterList::Create`
at the various call sites.
Serialization changes will addressed as the Concepts implementation
becomes more solid.
Drive-by fix:
This change also replaces the custom
`FixedSizeTemplateParameterListStorage` implementation with one that
follows the interface provided by `llvm::TrailingObjects`.
Reviewers: aaron.ballman, faisalv, rsmith
Subscribers: cfe-commits, nwilson
Differential Revision: https://reviews.llvm.org/D19322
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276069 91177308-0d34-0410-b5e6-96231b3b80d8
These ExprWithCleanups are added for holding a RunCleanupsScope not
for destructor calls; rather, they are for lifetime marks. This requires
ExprWithCleanups to keep a bit to indicate whether it have cleanups with
side effects (e.g. dtor calls).
Differential Revision: http://reviews.llvm.org/D20498
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272296 91177308-0d34-0410-b5e6-96231b3b80d8
if we are parsing a template specialization.
This commit makes changes to clear the TemplateParamScope bit and set
the TemplateParamParent field of the current scope to null if a template
specialization is being parsed.
Before this commit, Sema::ActOnStartOfLambdaDefinition would check
whether the parent template scope had any decls to determine whether
or not a template specialization was being parsed. This wasn't correct
since it couldn't distinguish between a real template specialization and
a template defintion with an unnamed template parameter (only template
parameters with names are added to the scope's decl list). To fix the
bug, this commit changes the code to check the pointer to the parent
template scope rather than the decl list.
rdar://problem/23440346
Differential Revision: http://reviews.llvm.org/D19175
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@267975 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264513 91177308-0d34-0410-b5e6-96231b3b80d8
lambda-expression. We don't actually instantiate the closure type / operator()
in the template in order to produce the closure type / operator() in the
instantiation, so this isn't caught by the normal path.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264184 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263921 91177308-0d34-0410-b5e6-96231b3b80d8
C++14 generic lambdas. It conflicts with the C++14 return type deduction
mechanism, and results in us failing to actually deduce the lambda's return
type in some cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259609 91177308-0d34-0410-b5e6-96231b3b80d8
`pass_object_size` is our way of enabling `__builtin_object_size` to
produce high quality results without requiring inlining to happen
everywhere.
A link to the design doc for this attribute is available at the
Differential review link below.
Differential Revision: http://reviews.llvm.org/D13263
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@254554 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252688 91177308-0d34-0410-b5e6-96231b3b80d8
Objective-C ARC lifetime qualifiers are dropped when canonicalizing
function types. Perform the same adjustment before comparing the
deduced result types of lambdas. Fixes rdar://problem/22344904.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249065 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we'd try to perform checks on the captures from the middle of
parsing the lambda's body, at the point where we detected that a variable
needed to be captured. This was wrong in a number of subtle ways. In
PR23334, we couldn't correctly handle the list of potential odr-uses
resulting from the capture, and our attempt to recover from that resulted
in a use-after-free.
We now defer building the initialization expression until we leave the lambda
body and return to the enclosing context, where the initialization does the
right thing. This patch only covers lambda-expressions, but we should apply
the same change to blocks and captured statements too.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@235921 91177308-0d34-0410-b5e6-96231b3b80d8
Update the test cases to pass when lambda call operators use thiscall.
Update the lambda-to-block conversion operator to use the default free
function calling convention instead of the call operator's convention.
This reverts commit r233082 and re-instates r233023.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233835 91177308-0d34-0410-b5e6-96231b3b80d8
Changes diagnostic options, language standard options, diagnostic identifiers, diagnostic wording to use c++14 instead of c++1y. It also modifies related test cases to use the updated diagnostic wording.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215982 91177308-0d34-0410-b5e6-96231b3b80d8
switch CurContext due to class template instantiation.
Fixes crash of the included test case.
rdar://16527205
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@207325 91177308-0d34-0410-b5e6-96231b3b80d8
Replacing llvm::copy changes with SmallVector range-based construction which is a considerably cleaner approach.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203461 91177308-0d34-0410-b5e6-96231b3b80d8
DR18 previously forebode typedefs to be used as parameter types if they
were of type 'void'. DR577 allows 'void' to be used as a function
parameter type regardless from where it came.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201631 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith