| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
initializers of data members (both static and non-static).
llvm-svn: 151017
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
default arguments of function parameters. This simple-sounding task is
complicated greatly by two issues:
(1) Default arguments aren't actually a real context, so we need to
maintain extra state within lambda expressions to track when a
lambda was actually in a default argument.
(2) At the time that we parse a default argument, the FunctionDecl
doesn't exist yet, so lambda closure types end up in the enclosing
context. It's not clear that we ever want to change that, so instead
we introduce the notion of the "effective" context of a declaration
for the purposes of name mangling.
llvm-svn: 151011
|
| |
|
|
| |
llvm-svn: 151005
|
| |
|
|
|
|
|
| |
explicit specialization of a function template, mark the instantiation as
constexpr if the specialization is, rather than requiring them to match.
llvm-svn: 151001
|
| |
|
|
|
|
|
|
|
| |
and introducing the lambda closure type and its function call
operator. Previously, we assumed that the lambda closure type would
land directly in the current context, and not some parent context (as
occurs with linkage specifications). Thanks to Richard for the test case.
llvm-svn: 150987
|
| |
|
|
|
|
|
| |
modern meta-data translation by commenting out private ivar
declarations in user source. Also, added several tests.
llvm-svn: 150985
|
| |
|
|
|
|
|
| |
of that variable; it will need to be recomputed with the resolved
type.
llvm-svn: 150984
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
name mangling in the Itanium C++ ABI for lambda expressions is so
dependent on context, we encode the number used to encode each lambda
as part of the lambda closure type, and maintain this value within
Sema.
Note that there are a several pieces still missing:
- We still get the linkage of lambda expressions wrong
- We aren't properly numbering or mangling lambda expressions that
occur in default function arguments or in data member initializers.
- We aren't (de-)serializing the lambda numbering tables
llvm-svn: 150982
|
| |
|
|
| |
llvm-svn: 150933
|
| |
|
|
|
|
| |
crash by repeating an old hack.
llvm-svn: 150925
|
| |
|
|
|
|
| |
thing in CodeGen, in that it never destructs anything.
llvm-svn: 150922
|
| |
|
|
| |
llvm-svn: 150919
|
| |
|
|
|
|
| |
rather than an lvalue referring to the scalar.
llvm-svn: 150889
|
| |
|
|
| |
llvm-svn: 150882
|
| |
|
|
|
|
| |
This fixes PR5172 and allows clang to compile C++ programs on Solaris using the system headers.
llvm-svn: 150881
|
| |
|
|
| |
llvm-svn: 150877
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
variable; it was previously duplicated, and one of the copies failed
to account for outer non-mutable lambda captures.
llvm-svn: 150872
|
| |
|
|
|
|
|
|
| |
<rdar://problem/10885993>.
This should probably be refactored... but it isn't completely obvious what refactoring is best.
llvm-svn: 150869
|
| |
|
|
|
|
|
|
|
|
| |
We had two separate issues here: firstly, varions functions were assuming that
they did not need to perform semantic checks on trivial destructors (this is
not true in C++11, where a trivial destructor can nonetheless be private or
deleted), and a bunch of DiagnoseUseOfDecl calls were missing for uses of
destructors.
llvm-svn: 150866
|
| |
|
|
|
|
|
|
|
| |
decent diagnostics. Finish the work of combining all the 'ShouldDelete'
functions into one. In unifying the code, fix a minor bug where an anonymous
union with a deleted default constructor as a member of a union wasn't being
considered as making the outer union's default constructor deleted.
llvm-svn: 150862
|
| |
|
|
|
|
| |
Don't know what I was thinking there. Fixes PR12023.
llvm-svn: 150804
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now generate temporary arrays to back std::initializer_list objects
initialized with braces. The initializer_list is then made to point at
the array. We support both ptr+size and start+end forms, although
the latter is untested.
Array lifetime is correct for temporary std::initializer_lists (e.g.
call arguments) and local variables. It is untested for new expressions
and member initializers.
Things left to do:
Massively increase the amount of testing. I need to write tests for
start+end init lists, temporary objects created as a side effect of
initializing init list objects, new expressions, member initialization,
creation of temporary objects (e.g. std::vector) for initializer lists,
and probably more.
Get lifetime "right" for member initializers and new expressions. Not
that either are very useful.
Implement list-initialization of array new expressions.
llvm-svn: 150803
|
| |
|
|
|
|
| |
we're capturing it by value in a non-mutable lambda.
llvm-svn: 150791
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
conversion to function pointer. Rather than having IRgen synthesize
the body of this function, we instead introduce a static member
function "__invoke" with the same signature as the lambda's
operator() in the AST. Sema then generates a body for the conversion
to function pointer which simply returns the address of __invoke. This
approach makes it easier to evaluate a call to the conversion function
as a constant, makes the linkage of the __invoke function follow the
normal rules for member functions, and may make life easier down the
road if we ever want to constexpr'ify some of lambdas.
Note that IR generation is responsible for filling in the body of
__invoke (Sema just adds a dummy body), because the body can't
generally be expressed in C++.
Eli, please review!
llvm-svn: 150783
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
loop and switch statements, by teaching Scope that a function scope never has
a continue/break parent for the purposes of control flow. Remove the hack in
block and lambda expressions which worked around this by pretending that such
expressions were continue/break scopes.
Remove Scope::ControlParent, since it's unused.
In passing, teach default statements to recover properly from a missing ';', and
add a fixit for same to both default and case labels (the latter already
recovered correctly).
llvm-svn: 150776
|
| |
|
|
|
|
|
|
| |
Don't try to typo-correct a method redeclaration to declarations not in
the current record as it could lead to infinite recursion if CorrectTypo
finds more than one correction candidate in a parent record.
llvm-svn: 150735
|
| |
|
|
|
|
|
|
|
| |
even if they are not within a function scope. Teach template
instantiation to treat them as such, and make sure that we have a
local instantiation scope when instantiating default arguments and
static data members.
llvm-svn: 150725
|
| |
|
|
|
|
| |
restriction and add some tests.
llvm-svn: 150721
|
| |
|
|
|
|
| |
completions that don't insert braces. Fixes <rdar://problem/10764168>.
llvm-svn: 150707
|
| |
|
|
|
|
|
|
|
|
| |
rdar://10289283
Also fix the fixit (oh the irony) when it uses CFBridgingRetain/CFBridgingRelease;
they are supposed to be calls with the casted expression as parameter, they should
not be inserted into the cast like the __bridge keywords.
llvm-svn: 150705
|
| |
|
|
|
|
| |
dependent attributes on static members of templatized classes.
llvm-svn: 150704
|
| |
|
|
| |
llvm-svn: 150702
|
| |
|
|
|
|
| |
This finishes generalized initializer support in Sema.
llvm-svn: 150688
|
| |
|
|
|
|
|
|
| |
hold the used constructor itself.""
This reintroduces commit r150682 with a fix for the Bullet benchmark crash.
llvm-svn: 150685
|
| |
|
|
|
|
|
|
|
|
| |
used constructor itself."
It leads to a compiler crash in the Bullet benchmark.
This reverts commit r12014.
llvm-svn: 150684
|
| |
|
|
|
|
|
|
|
|
| |
constructor itself.
Holding the constructor directly makes no sense when list-initialized arrays come into play. The constructor is now held in a CXXConstructExpr, if construction is what is done. The new design can also distinguish properly between list-initialization and direct-initialization, as well as implicit default-initialization constructors and explicit value-initialization constructors. Finally, doing it this way removes redundance from the AST because CXXNewExpr doesn't try to handle both the allocation and the initialization responsibilities.
This breaks the static analysis of new expressions. I've filed PR12014 to track this.
llvm-svn: 150682
|
| |
|
|
|
|
| |
so -fms-extensions doesn't affect enum semantics in incompatible ways. <rdar://problem/10657186>.
llvm-svn: 150663
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
pointers and block pointers). We use dummy definitions to keep the
invariant that an implicit, used definition has a body; IR generation
will substitute the actual contents, since they can't be represented
as C++.
For the block pointer case, compute the copy-initialization needed to
capture the lambda object in the block, which IR generation will need
later.
llvm-svn: 150645
|
| |
|
|
| |
llvm-svn: 150629
|
| |
|
|
|
|
| |
parenthesized braced-init-list in the base/member initialization list.
llvm-svn: 150625
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Snooping in other namespaces when the identifier being corrected is
already qualified (i.e. a valid CXXScopeSpec is passed to CorrectTypo)
and ranking synthesized namespace qualifiers relative to the existing
qualifier is now performed. Support for disambiguating the string
representation of synthesized namespace qualifers has also been added
(the change to test/Parser/cxx-using-directive.cpp is an example of an
ambiguous relative qualifier).
llvm-svn: 150622
|
| |
|
|
|
|
|
|
|
|
|
| |
with the same parameter types and return type as the function call
operator. This is the real answer to
http://stackoverflow.com/questions/4148242/is-it-possible-to-convert-a-c0x-lambda-to-a-clang-block
:)
llvm-svn: 150620
|
| |
|
|
|
|
| |
function declaration into a separate function. No functionality change
llvm-svn: 150617
|
| |
|
|
|
|
|
|
|
| |
function, provide a specialized diagnostic that indicates the kind of
special member function (default constructor, copy assignment
operator, etc.) and that it was implicitly deleted. Add a hook where
we can provide more detailed information later.
llvm-svn: 150611
|
| |
|
|
|
|
| |
specialize location information and diagnostics for this entity.
llvm-svn: 150588
|
| |
|
|
| |
llvm-svn: 150586
|
| |
|
|
| |
llvm-svn: 150585
|
| |
|
|
|
|
|
| |
return statements within a lambda; this diagnostic previously referred
to blocks.
llvm-svn: 150584
|
| |
|
|
| |
llvm-svn: 150583
|