Specifically, the following features are not included in this commit:
- any sort of capturing within generic lambdas
- nested lambdas
- conversion operator for captureless lambdas
- ensuring all visitors are generic lambda aware
As an example of what compiles:
template <class F1, class F2>
struct overload : F1, F2 {
using F1::operator();
using F2::operator();
overload(F1 f1, F2 f2) : F1(f1), F2(f2) { }
};
auto Recursive = [](auto Self, auto h, auto ... rest) {
return 1 + Self(Self, rest...);
};
auto Base = [](auto Self, auto h) {
return 1;
};
overload<decltype(Base), decltype(Recursive)> O(Base, Recursive);
int num_params = O(O, 5, 3, "abc", 3.14, 'a');
Please see attached tests for more examples.
Some implementation notes:
- Add a new Declarator context => LambdaExprParameterContext to
clang::Declarator to allow the use of 'auto' in declaring generic
lambda parameters
- Augment AutoType's constructor (similar to how variadic
template-type-parameters ala TemplateTypeParmDecl are implemented) to
accept an IsParameterPack to encode a generic lambda parameter pack.
- Add various helpers to CXXRecordDecl to facilitate identifying
and querying a closure class
- LambdaScopeInfo (which maintains the current lambda's Sema state)
was augmented to house the current depth of the template being
parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth)
so that Sema::ActOnLambdaAutoParameter may use it to create the
appropriate list of corresponding TemplateTypeParmDecl for each
auto parameter identified within the generic lambda (also stored
within the current LambdaScopeInfo). Additionally,
a TemplateParameterList data-member was added to hold the invented
TemplateParameterList AST node which will be much more useful
once we teach TreeTransform how to transform generic lambdas.
- SemaLambda.h was added to hold some common lambda utility
functions (this file is likely to grow ...)
- Teach Sema::ActOnStartOfFunctionDef to check whether it
is being called to instantiate a generic lambda's call
operator, and if so, push an appropriately prepared
LambdaScopeInfo object on the stack.
- Teach Sema::ActOnStartOfLambdaDefinition to set the
return type of a lambda without a trailing return type
to 'auto' in C++1y mode, and teach the return type
deduction machinery in SemaStmt.cpp to process either
C++11 and C++14 lambda's correctly depending on the flag.
- various tests were added - but much more will be needed.
A greatful thanks to all reviewers including Eli Friedman,
James Dennett and the ever illuminating Richard Smith. And
yet I am certain that I have allowed unidentified bugs to creep in;
bugs, that I will do my best to slay, once identified!
Thanks!
llvm-svn: 188977
Summary:
Source-centric tools need access to the location of a C++11
lambda expression's capture-default ('&' or '=') when it's present.
It's possible for them to find it by re-lexing and re-implementing
rules that Clang's parser has already applied, but the cost of storing
the SourceLocation and making it available to them is 32 bits per
LambdaExpr (a small delta, proportionally), and the simplification in
client code is significant.
Reviewers: rsmith
Reviewed By: rsmith
CC: cfe-commits, klimek, revane
Differential Revision: http://llvm-reviews.chandlerc.com/D1192
llvm-svn: 188121
Compute mangling numbers for externally visible local variables and tags.
Change the mangler to consistently use discriminators where necessary.
Tweak the scheme we use to number decls which are not externally visible
to avoid unnecessary discriminators in common cases now that we request
them more consistently.
Fixes <rdar://problem/14204721>.
llvm-svn: 185986
Blocks, like lambdas, can be written in contexts which are required to be
treated as the same under ODR. Unlike lambdas, it isn't possible to actually
take the address of a block, so the mangling of the block itself doesn't
matter. However, objects like static variables inside a block do need to
be mangled in a consistent way.
There are basically three components here. One, block literals need a
consistent numbering. Two, objects/types inside a block literal need
to be mangled using it. Three, objects/types inside a block literal need
to have their linkage computed correctly.
llvm-svn: 185372
correctly in the presence of qualified types.
(I had to change the unittest because it was trying to cast a
QualifiedTypeLoc to TemplateSpecializationTypeLoc.)
llvm-svn: 183563
correctly aligned. Not performing such computations led to misaligned loads,
which crash on some platforms and are generally bad on other platforms.
The implementation of TypeLocBuilder::pushImpl is rather messy; code using
TypeLocBuilder accidentally assumes that partial TypeLocs are
laid out like a complete TypeLoc. As a followup, I intend to work on
fixing the TypeLocBuilder API to avoid exposing partial TypeLocs; this should
substantially simplify the implemementation.
Fixes PR16144.
llvm-svn: 183466
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
the actual parser and support arbitrary id-expressions.
We're actually basically set up to do arbitrary expressions here
if we wanted to.
Assembly operands permit things like A::x to be written regardless
of language mode, which forces us to embellish the evaluation
context logic somewhat. The logic here under template instantiation
is incorrect; we need to preserve the fact that an expression was
unevaluated. Of course, template instantiation in general is fishy
here because we have no way of delaying semantic analysis in the
MC parser. It's all just fishy.
I've also fixed the serialization of MS asm statements.
This commit depends on an LLVM commit.
llvm-svn: 180976
Add CapturedDecl to be the DeclContext for CapturedStmt, and perform semantic
analysis. Currently captures all variables by reference.
TODO: templates
Author: Ben Langmuir <ben.langmuir@intel.com>
Differential Revision: http://llvm-reviews.chandlerc.com/D433
llvm-svn: 179618
http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb went back green
before it processed the reverted 178663, so it could not have been the culprit.
Revert "Revert 178663."
This reverts commit 4f8a3eb2ce5d4ba422483439e20c8cbb4d953a41.
llvm-svn: 178682
For variables and functions clang used to store two storage classes. The one
"as written" in the code and a patched one, which, for example, propagates
static to the following decls.
This apparently is from the days clang lacked linkage computation. It is now
redundant and this patch removes it.
llvm-svn: 178663
so that it looks through certain syntactic forms and applies
even if normal inference would have succeeded.
There is potential for source incompatibility from this
change, but overall we feel that it produces a much
cleaner and more defensible result, and the block
compatibility rules should curb a lot of the potential
for annoyance.
rdar://13200889
llvm-svn: 176743
This does limit these typedefs to being sequences, but no current usage
requires them to be contiguous (we could expand this to a more general
iterator pair range concept at some point).
Also, it'd be nice if SmallVector were constructible directly from an ArrayRef
but this is a bit tricky since ArrayRef depends on SmallVectorBaseImpl for the
inverse conversion. (& generalizing over all range-like things, while nice,
would require some nontrivial SFINAE I haven't thought about yet)
llvm-svn: 170482
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
definition info; it needs to be there because the mangler needs to
access it before we're finished defining the lambda class.
PR12808.
llvm-svn: 164186
This also provides isConst/Volatile/Restrict on FunctionTypes to coalesce
the implementation with other callers (& update those other callers).
Patch contributed by Sam Panzer (panzer@google.com).
llvm-svn: 161647
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
change once it's been assigned. It can change in two ways:
1) In a template instantiation, the context declaration should be the
instantiated declaration, not the declaration in the template.
2) If a lambda appears in the pattern of a variadic pack expansion, the
mangling number will depend on the pack length.
llvm-svn: 160614
In C, enum constants have the type of the enum's underlying integer type,
rather than the type of the enum. (This is not true in C++.) Thus, when a
block's return type is inferred from an enum constant, it is incompatible
with expressions that return the enum type.
In r158899, I told block returns to pretend that enum constants have enum
type, like in C++. Doug Gregor pointed out that this can break existing code.
Now, we don't check the types of return statements until the end of the block.
This lets us go back and add implicit casts in blocks with mixed enum
constants and enum-typed expressions.
<rdar://problem/11662489> (again)
llvm-svn: 159591
In addition, I've made the pointer and reference typedef 'void' rather than T*
just so they can't get misused. I would've omitted them entirely but
std::distance likes them to be there even if it doesn't use them.
This rolls back r155808 and r155869.
Review by Doug Gregor incorporating feedback from Chandler Carruth.
llvm-svn: 158104
filter_decl_iterator had a weird mismatch where both op* and op-> returned T*
making it difficult to generalize this filtering behavior into a reusable
library of any kind.
This change errs on the side of value, making op-> return T* and op* return
T&.
(reviewed by Richard Smith)
llvm-svn: 155808
number + context) to the point where we initially start defining the
lambda, so that the linkage won't change when that information is made
available. Fixes the assertion in <rdar://problem/11182962>.
Plus, actually mangle the context of lambdas properly.
llvm-svn: 154029
Note that this transformation has a substantial semantic effect outside of ARC: it gives the converted lambda lifetime semantics similar to a block literal. With ARC, the effect is much less obvious because the lifetime of blocks is already managed.
llvm-svn: 151797
block pointer that returns a block literal which captures (by copy)
the lambda closure itself. Some aspects of the block literal are left
unspecified, namely the capture variable (which doesn't actually
exist) and the body (which will be filled in by IRgen because it can't
be written as an AST).
Because we're switching to this model, this patch also eliminates
tracking the copy-initialization expression for the block capture of
the conversion function, since that information is now embedded in the
synthesized block literal. -1 side tables FTW.
llvm-svn: 151131
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
