Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1 |
|
#
58ea1059 |
| 23-Apr-2020 |
Haojian Wu <hokein.wu@gmail.com> |
[AST][RecoveryExpr] Build recovery expressions by default for C++.
Reland https://reviews.llvm.org/D76696 All known crashes have been fixed, another attemption.
We have rolled out this to all inter
[AST][RecoveryExpr] Build recovery expressions by default for C++.
Reland https://reviews.llvm.org/D76696 All known crashes have been fixed, another attemption.
We have rolled out this to all internal users for a while, didn't see big issues, we consider it is stable enough.
Reviewed By: sammccall
Subscribers: rsmith, hubert.reinterpretcast, ebevhan, jkorous, arphaman, kadircet, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D78350
show more ...
|
#
62dea6e9 |
| 26-Mar-2020 |
Haojian Wu <hokein.wu@gmail.com> |
Revert "[AST] Build recovery expressions by default for C++."
This reverts commit 0788acbccbec094903a3425ffe5a98f8d55cbd64. This reverts commit c2d7a1f79cedfc9fcb518596aa839da4de0adb69: Revert "[cl
Revert "[AST] Build recovery expressions by default for C++."
This reverts commit 0788acbccbec094903a3425ffe5a98f8d55cbd64. This reverts commit c2d7a1f79cedfc9fcb518596aa839da4de0adb69: Revert "[clangd] Add test for FindTarget+RecoveryExpr (which already works). NFC"
It causes a crash on invalid code:
class X { decltype(unresolved()) foo; }; constexpr int s = sizeof(X);
show more ...
|
#
0788acbc |
| 24-Mar-2020 |
Haojian Wu <hokein.wu@gmail.com> |
[AST] Build recovery expressions by default for C++.
Update the existing tests.
Reviewers: sammccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D76696
|
Revision tags: llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1, llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2, llvmorg-4.0.1-rc1, llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1, llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1, llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1, llvmorg-3.8.1, llvmorg-3.8.1-rc1, llvmorg-3.8.0, llvmorg-3.8.0-rc3, llvmorg-3.8.0-rc2, llvmorg-3.8.0-rc1, llvmorg-3.7.1, llvmorg-3.7.1-rc2, llvmorg-3.7.1-rc1 |
|
#
42b10572 |
| 11-Nov-2015 |
Richard Smith <richard-llvm@metafoo.co.uk> |
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 C
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
show more ...
|
Revision tags: llvmorg-3.7.0, llvmorg-3.7.0-rc4, llvmorg-3.7.0-rc3, studio-1.4, llvmorg-3.7.0-rc2, llvmorg-3.7.0-rc1, llvmorg-3.6.2, llvmorg-3.6.2-rc1, llvmorg-3.6.1, llvmorg-3.6.1-rc1 |
|
#
c861f417 |
| 30-Apr-2015 |
Ben Langmuir <blangmuir@apple.com> |
Fix the end location of init-capture annotations in ObjC++
And thereby stop asserting.
In ObjC++ modes, we tentatively parse the lambda introducer twice: once to disambiguate designators, which we
Fix the end location of init-capture annotations in ObjC++
And thereby stop asserting.
In ObjC++ modes, we tentatively parse the lambda introducer twice: once to disambiguate designators, which we also do in C++, and a second time to disambiguate objc message expressions. During the second tentative parse, the last cached token will be the annotation token we built in the first parse. So use getLastLoc() to get the correct end location for the rebuilt annotation.
llvm-svn: 236246
show more ...
|
Revision tags: llvmorg-3.5.2, llvmorg-3.5.2-rc1, llvmorg-3.6.0, llvmorg-3.6.0-rc4, llvmorg-3.6.0-rc3 |
|
#
215f423f |
| 11-Feb-2015 |
Richard Smith <richard-llvm@metafoo.co.uk> |
Add a warning for direct-list-initialization of a variable with a deduced type (or of a lambda init-capture, which is sort-of such a variable). The semantics of such constructs will change when we im
Add a warning for direct-list-initialization of a variable with a deduced type (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
show more ...
|
Revision tags: llvmorg-3.6.0-rc2, llvmorg-3.6.0-rc1, llvmorg-3.5.1, llvmorg-3.5.1-rc2, llvmorg-3.5.1-rc1, llvmorg-3.5.0, llvmorg-3.5.0-rc4, llvmorg-3.5.0-rc3, llvmorg-3.5.0-rc2, llvmorg-3.5.0-rc1, llvmorg-3.4.2, llvmorg-3.4.2-rc1, llvmorg-3.4.1, llvmorg-3.4.1-rc2, llvmorg-3.4.1-rc1, llvmorg-3.4.0, llvmorg-3.4.0-rc3, llvmorg-3.4.0-rc2, llvmorg-3.4.0-rc1 |
|
#
5b013f50 |
| 28-Sep-2013 |
Richard Smith <richard-llvm@metafoo.co.uk> |
Add compat/extension warnings for init captures.
llvm-svn: 191609
|
Revision tags: llvmorg-3.3.1-rc1, llvmorg-3.3.0, llvmorg-3.3.0-rc3, llvmorg-3.3.0-rc2 |
|
#
f44d2a8a |
| 21-May-2013 |
Richard Smith <richard-llvm@metafoo.co.uk> |
PR16094: I should have known Obj-C init-capture disambiguation couldn't be *that* easy...
Try a bit harder to disambiguate. This is mostly straightforward, but for =-style initializers, we actually
PR16094: I should have known Obj-C init-capture disambiguation couldn't be *that* easy...
Try a bit harder to disambiguate. This is mostly straightforward, but for =-style initializers, we actually need to know where an expression ends:
[foo = bar baz]
is a message send, whereas
[foo = bar + baz]
is a lambda-introducer. Handle this by parsing the expression eagerly, and replacing it with an annotation token. By chance, we use the *exact same* parsing rules in both cases (except that we need to assume we're inside a message send for the parse, to turn off various forms of inapplicable error recovery).
llvm-svn: 182432
show more ...
|
#
ba71c085 |
| 16-May-2013 |
Richard Smith <richard-llvm@metafoo.co.uk> |
First pass of semantic analysis for init-captures: check the initializer, build a FieldDecl from it, and propagate both into the closure type and the LambdaExpr.
You can't do much useful with them y
First pass of semantic analysis for init-captures: check the initializer, build a FieldDecl from it, and propagate both into the closure type and the LambdaExpr.
You can't do much useful with them yet -- you can't use them within the body of the lambda, because we don't have a representation for "the this of the lambda, not the this of the enclosing context". We also don't have support or a representation for a nested capture of an init-capture yet, which was intended to work despite not being allowed by the current standard wording.
llvm-svn: 181985
show more ...
|
#
21b3ab43 |
| 09-May-2013 |
Richard Smith <richard-llvm@metafoo.co.uk> |
C++1y n3648: parse and reject init-captures for now.
llvm-svn: 181553
|
Revision tags: llvmorg-3.3.0-rc1 |
|
#
c084bd28 |
| 02-Feb-2013 |
Richard Smith <richard-llvm@metafoo.co.uk> |
PR15132: Replace "address expression must be an lvalue or a function designator" diagnostic with more correct and more human-friendly "cannot take address of rvalue of type 'T'".
For the case of & &
PR15132: Replace "address expression must be an lvalue or a function designator" diagnostic with more correct and more human-friendly "cannot take address of rvalue of type 'T'".
For the case of & &T::f, provide a custom diagnostic, rather than unhelpfully saying "cannot take address of rvalue of type '<overloaded function type>'".
For the case of &array_temporary, treat it just like a class temporary (including allowing it as an extension); the existing diagnostic wording for the class temporary case works fine.
llvm-svn: 174262
show more ...
|
Revision tags: llvmorg-3.2.0, llvmorg-3.2.0-rc3, llvmorg-3.2.0-rc2, llvmorg-3.2.0-rc1, llvmorg-3.1.0, llvmorg-3.1.0-rc3, llvmorg-3.1.0-rc2, llvmorg-3.1.0-rc1 |
|
#
656bc62a |
| 09-Feb-2012 |
Douglas Gregor <dgregor@apple.com> |
Remove the "unsupported" error for lambda expressions. It's annoying, and rapidly becoming untrue.
llvm-svn: 150165
|
#
9390e9cc |
| 09-Feb-2012 |
Douglas Gregor <dgregor@apple.com> |
Fix yet one more test
llvm-svn: 150129
|
#
34b49061 |
| 26-Jan-2012 |
Eli Friedman <eli.friedman@gmail.com> |
Refactor to share code for handling return statements between lambda expressions and block literals. As it turns out, almost all the logic can be shared.
llvm-svn: 149031
|
#
73a04090 |
| 07-Jan-2012 |
Eli Friedman <eli.friedman@gmail.com> |
More lambda work: semantic analysis of capturing 'this'. It's a bit complicated, but we have to be careful about when exactly captures are marked given PotentiallyPotentiallyEvaluated contexts. (Ac
More lambda work: semantic analysis of capturing 'this'. It's a bit complicated, but we have to be careful about when exactly captures are marked given PotentiallyPotentiallyEvaluated contexts. (Actually, it's not 100% correct yet, but it's close enough for the moment.)
llvm-svn: 147723
show more ...
|
#
71c8055f |
| 05-Jan-2012 |
Eli Friedman <eli.friedman@gmail.com> |
More lambda work. Tweak the Sema interface slightly. Start adding the pieces to build the lambda class and its call operator. Create an actual scope for the lambda body.
llvm-svn: 147595
|
#
c7c97144 |
| 04-Jan-2012 |
Eli Friedman <eli.friedman@gmail.com> |
Stub out the Sema interface for lambda expressions, and change the parser to use it. Unconditionally error on lambda expressions because they don't work in any meaningful way yet.
llvm-svn: 147515
|
Revision tags: llvmorg-3.0.0, llvmorg-3.0.0-rc4, llvmorg-3.0.0-rc3, llvmorg-3.0.0-rc2, llvmorg-3.0.0-rc1 |
|
#
9ca5c425 |
| 13-Oct-2011 |
Richard Smith <richard-llvm@metafoo.co.uk> |
Update all tests other than Driver/std.cpp to use -std=c++11 rather than -std=c++0x. Patch by Ahmed Charles!
llvm-svn: 141900
|
#
db0b9f12 |
| 04-Aug-2011 |
Douglas Gregor <dgregor@apple.com> |
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie!
llvm-svn: 136876
|