s/instantate/instantiate/ throughout. NFCI.

The static_assert in "libcxx/include/memory" was the main offender here,
but then I figured I might as well `git grep -i instantat` and fix all
the instan

s/instantate/instantiate/ throughout. NFCI.

The static_assert in "libcxx/include/memory" was the main offender here,
but then I figured I might as well `git grep -i instantat` and fix all
the instances I found. One was in user-facing HTML documentation;
the rest were in comments or tests.

show more ...

[Sema] Remove location from implicit capture init expr

A lambda's closure is initialized when the lambda is declared. For
implicit captures, the initialization code emitted from EmitLambdaExpr
refer

[Sema] Remove location from implicit capture init expr

A lambda's closure is initialized when the lambda is declared. For
implicit captures, the initialization code emitted from EmitLambdaExpr
references source locations *within the lambda body* in the function
containing the lambda. This results in a poor debugging experience: we
step to the line containing the lambda, then into lambda, out again,
over and over, until every capture's field is initialized.

To improve stepping behavior, assign the starting location of the lambda
to expressions which initialize an implicit capture within it.

rdar://39807527

Differential Revision: https://reviews.llvm.org/D50927

llvm-svn: 342194

show more ...

PR38627: Fix handling of exception specification adjustment for
destructors.

We previously tried to patch up the exception specification after
completing the class, which went wrong when the excepti

PR38627: Fix handling of exception specification adjustment for
destructors.

We previously tried to patch up the exception specification after
completing the class, which went wrong when the exception specification
was needed within the class body (in particular, by a friend
redeclaration of the destructor in a nested class). We now mark the
destructor as having a not-yet-computed exception specification
immediately after creating it.

This requires delaying various checks against the exception
specification (where we'd previously have just got the wrong exception
specification, and now find we have an exception specification that we
can't compute yet) when those checks fire while the class is being
defined.

This also exposed an issue that we were missing a CodeSynthesisContext
for computation of exception specifications (otherwise we'd fail to make
the module containing the definition of the class visible when computing
its members' exception specs). Adding that incidentally also gives us a
diagnostic quality improvement.

This has also exposed an pre-existing problem: making the exception
specification evaluation context a non-SFINAE context (as it should be)
results in a bootstrap failure; PR38850 filed for this.

llvm-svn: 341499

show more ...

PR23135: Don't instantiate constexpr functions referenced in unevaluated operands where possible.

This implements something like the current direction of DR1581: we use a narrow
syntactic check to d

PR23135: Don't instantiate constexpr functions referenced in unevaluated operands where possible.

This implements something like the current direction of DR1581: we use a narrow
syntactic check to determine the set of places where a constant expression
could be evaluated, and only instantiate a constexpr function or variable if
it's referenced in one of those contexts, or is odr-used.

It's not yet clear whether this is the right set of syntactic locations; we
currently consider all contexts within templates that would result in odr-uses
after instantiation, and contexts within list-initialization (narrowing
conversions take another victim...), as requiring instantiation. We could in
principle restrict the former cases more (only const integral / reference
variable initializers, and contexts in which a constant expression is required,
perhaps). However, this is sufficient to allow us to accept libstdc++ code,
which relies on GCC's behavior (which appears to be somewhat similar to this
approach).

llvm-svn: 291318

show more ...

Clarify the error message when the reason the conversion is not viable is because the returned value does not match the function return type.

llvm-svn: 245979

PR23334: Perform semantic checking of lambda capture initialization in the right context.

Previously we'd try to perform checks on the captures from the middle of
parsing the lambda's body, at the p

PR23334: Perform semantic checking of lambda capture initialization in the right context.

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.

llvm-svn: 235921

show more ...

Handle use of default member initializers before end of outermost class

Specifically, when we have this situation:
struct A {
template <typename T> struct B {
int m1 = sizeof(A);
};

Handle use of default member initializers before end of outermost class

Specifically, when we have this situation:
struct A {
template <typename T> struct B {
int m1 = sizeof(A);
};
B<int> m2;
};

We can't parse m1's initializer eagerly because we need A to be
complete. Therefore we wait until the end of A's class scope to parse
it. However, we can trigger instantiation of B before the end of A,
which will attempt to instantiate the field decls eagerly, and it would
build a bad field decl instantiation that said it had an initializer but
actually lacked one.

Fixed by deferring instantiation of default member initializers until
they are needed during constructor analysis. This addresses a long
standing FIXME in the code.

Fixes PR19195.

Reviewed By: rsmith

Differential Revision: http://reviews.llvm.org/D5690

llvm-svn: 222192

show more ...

Implement C++11 semantics for [[noreturn]] attribute. This required splitting
it apart from [[gnu::noreturn]] / __attribute__((noreturn)), since their
semantics are not equivalent (for instance, we t

Implement C++11 semantics for [[noreturn]] attribute. This required splitting
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).

llvm-svn: 172691

show more ...

Lambda closure types are always considered to be like "local" classes,
even if they are not within a function scope. Teach template
instantiation to treat them as such, and make sure that we have a
l

Lambda closure types are always considered to be like "local" classes,
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

show more ...

Specialize noreturn diagnostics for lambda expressions.

llvm-svn: 150586

Link together the call operator produced from transforming a lambda
expression with the original call operator, so that we don't try to
separately instantiate the call operator. Test and tweak a few

Link together the call operator produced from transforming a lambda
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.

llvm-svn: 150440

show more ...

Introduce support for template instantiation of lambda
expressions. This is mostly a simple refact, splitting the main "start
a lambda expression" function into smaller chunks that are driven
either

Introduce support for template instantiation of lambda
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.

llvm-svn: 150417

show more ...