| Age | Commit message (Collapse) | Author |
|---|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179688 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
return types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178081 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
therefore references to members should not be transformed into implicit uses of
'this'. Patch by Ismail Pazarbasi!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177134 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
it apart from [[gnu::noreturn]] / __attribute__((noreturn)), since their
semantics are not equivalent (for instance, we treat [[gnu::noreturn]] as
affecting the function type, whereas [[noreturn]] does not).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172691 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
function is selected by overload resolution.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171190 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
array-index starting values for the 'this' capture. Fixes
<rdar://problem/12426831>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166709 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166280 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
"expected" is at the start of the word and will no longer accept typos such as "junkexpected-*" as a valid "expected-*" directive. A very few test-cases had to be amended to adhere to the new rule.
Patch reviewed by David Blaikie.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166279 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160705 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
literal helper functions. All helper functions (global
and locals) use block_invoke as their prefix. Local literal
helper names are prefixed by their enclosing mangled function
names. Blocks in non-local initializers (e.g. a global variable
or a C++11 field) are prefixed by their mangled variable name.
The descriminator number added to end of the name starts off
with blank (for first block) and _<N> (for the N+2-th block).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159206 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
for unexpanded parameter packs. Fixes the crash-on-invalid in
PR13117.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158525 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157947 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
lambda as referring to a local in an enclosing scope if we're in the
enclosing scope of the lambda (not it's function call operator). Also,
turn the test into an IR generation test, since that's where the
crashes occurred. Really fixes PR12746 / <rdar://problem/11465120>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156926 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
blocks and lambdas, based heavily on a patch from Meador Inge. Fixes
PR12746 / <rdar://problem/11465120>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156925 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the parsing of such things appears to be a conforming extension, but it breaks
libstdc++4.7's std::pair.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155975 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
exception specifications on member functions until after the closing
'}' for the containing class. This allows, for example, a member
function to throw an instance of its own class. Fixes PR12564 and a
fairly embarassing oversight in our C++98/03 support.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154844 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
in the declaration of a non-static member function after the
(optional) cv-qualifier-seq, which in practice means in the exception
specification and late-specified return type.
The new scheme here used to manage 'this' outside of a member function
scope is more general than the Scope-based mechanism previously used
for non-static data member initializers and late-parsesd attributes,
because it can also handle the cv-qualifiers on the member
function. Note, however, that a separate pass is required for static
member functions to determine whether 'this' was used, because we
might not know that we have a static function until after declaration
matching.
Finally, this introduces name mangling for 'this' and for the implicit
'this', which is intended to match GCC's mangling. Independent
verification for the new mangling test case would be appreciated.
Fixes PR10036 and PR12450.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154799 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
* s/nonstatic/non-static/ in the diagnostics, since the latter form outvoted
the former by 28-2 in our diagnostics.
* Fix the "use of member in static member function" diagnostic to correctly
detect this situation inside a block or lambda.
* Produce a more specific "invalid use of non-static member" diagnostic for
the case where a nested class member refers to a member of a
lexically-surrounding class.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154073 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151699 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
unevaluated operands applies within member functions, too.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151443 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
lambda closure type's function pointer conversion over user-defined
conversion via a lambda closure type's block pointer conversion,
always. This is a preference for more-standard code (since blocks
are an extension) and a nod to efficiency, since function pointers
don't require any memory management. Fixes PR12063.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151170 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151131 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
that 'this' can be used in the brace-or-equal-initializer of a
non-static data member, and C++11 [expr.prim.lambda]p9, which says
that lambda expressions not in block scope can have no captures, side
fully with C++11 [expr.prim.general]p4 by allowing 'this' to be
captured within these initializers. This seems to be the intent of
non-static data member initializers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151101 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
arguments. There are two aspects to this:
- Make sure that when marking the declarations referenced in a
default argument, we don't try to mark local variables, both because
it's a waste of time and because the semantics are wrong: we're not
in a place where we could capture these variables again even if it
did make sense.
- When a lambda expression occurs in a default argument of a
function template, make sure that the corresponding closure type is
considered dependent, so that it will get properly instantiated. The
second bit is a bit of a hack; to fix it properly, we may have to
rearchitect our handling of default arguments, parsing them only
after creating the function definition. However, I'd like to
separate that work from the lambdas work.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151076 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150875 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
variable; it was previously duplicated, and one of the copies failed
to account for outer non-mutable lambda captures.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150872 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
we're capturing it by value in a non-mutable lambda.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150791 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150725 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150645 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
:)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150620 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150611 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150589 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
specialize location information and diagnostics for this entity.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150588 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150586 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
return statements within a lambda; this diagnostic previously referred
to blocks.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150584 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
lambda expressions. Because these issue was pulled back from Ready
status at the Kona meeting, we still emit an ExtWarn when using
default arguments for lambda expressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150519 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150503 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
[&values...] { print(values...); }
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150497 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
copy-capturing in lambdas
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150442 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
expression with the original call operator, so that we don't try to
separately instantiate the call operator. Test and tweak a few more
bits for template instantiation of lambda expressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150440 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
expressions. This is mostly a simple refact, splitting the main "start
a lambda expression" function into smaller chunks that are driven
either from the parser (Sema::ActOnLambdaExpr) or during AST
transformation (TreeTransform::TransformLambdaExpr). A few minor
interesting points:
- Added new entry points for TreeTransform, so that we can
explicitly establish the link between the lambda closure type in the
template and the lambda closure type in the instantiation.
- Added a bit into LambdaExpr specifying whether it had an explicit
result type or not. We should have had this anyway.
This code is 'lightly' tested.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150417 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
id-expression 'x' will compute the type based on the assumption that
'x' will be captured, even if it isn't captured, per C++11
[expr.prim.lambda]p18. There are two related refactors that go into
implementing this:
1) Split out the check that determines whether we should capture a
particular variable reference, along with the computation of the
type of the field, from the actual act of capturing the
variable.
2) Always compute the result of decltype() within Sema, rather than
AST, because the decltype() computation is now context-sensitive.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150347 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
assignment operator, per C++ [expr.prim.lambda]p19. Make it so.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150345 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
double-check that this is correct.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150292 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
recursive capture. This is far more interesting for IRgen.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150283 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
default arguments if in fact those lambdas capture any entity.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150282 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
default is '=', and reword the warning about explicitly capturing
'this' in such lambdas to indicate that only explicit capture is
banned.
Introduce Fix-Its for this and other "save the programmer from
themself" rules regarding what can be explicitly captured and what
must be implicitly captured.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150256 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
nested captures. We currently don't get odr-use correct in array
bounds, so that bit is commented out while we sort out what we need to
do.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150255 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
have finished parsing the body, so that name lookup will never find
anything within the closure type. Then, add this operator() and the
conversion function (if available) before completing the class.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150252 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150239 91177308-0d34-0410-b5e6-96231b3b80d8
|
