We don't yet support pointer-to-member template arguments that have undergone
pointer-to-member conversions, mostly because we don't have a mangling for them yet.
llvm-svn: 222807
GCC and ICC both reject this and the 'Runtime-sized arrays with
automatic storage duration' (N3639) paper forbade this as well.
Previously, we would crash on our way to mangling.
This fixes PR21632.
llvm-svn: 222569
If there is more than one TypoExpr within the expr being transformed and
any but the last TypoExpr seen don't have any viable candidates, the
tree transform will be aborted early and the remaining TypoExprs are
never seen and hence never diagnosed. This adds a simple
RecursiveASTVisitor to find all of the TypoExprs to be diagnosed in the
case where typo correction of the entire expr fails (and the result of
the tree transform is an ExprError).
llvm-svn: 222465
The default handling is extended to properly create member expressions
and Objective-C ivar references.
Also detect and reject cases where multiple corrections have identical
correction distances and are valid, instead of suggesting the first one
that is found.
llvm-svn: 222462
Summary:
Ok, here is somewhat addition to D6217 aiming to preserve old darwin behavior wrt the typedefed types. The actual change to SemaChecking turned out to be pretty gross, in particular:
1. We need to extract the typedef'ed type for proper diagnostics
2. We need to walk over paren expressions as well
Reviewers: chandlerc, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6256
llvm-svn: 222044
Summary:
Consider the following nifty 1 liner: (0 ? csqrtl(2.0f) : sqrtl(2.0f)). One can easily obtain such code from e.g. tgmath. Right now it produces an assertion because we fail to do the promotion real => _Complex real.
The case was properly handled previously (old handleOtherComplexFloatConversion routine), but was forgotten in the current version. This seems to be about fallout from r219557
Reviewers: chandlerc, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6217
llvm-svn: 221821
One takes an Expr* and the other is a simple wrapper that takes an
ExprResult instead, and handles checking whether the ExprResult is
invalid.
Additionally, allow an optional callback that is run on the full result
of the tree transform, for filtering potential corrections based on the
characteristics of the resulting expression once all of the typos have
been replaced.
llvm-svn: 221735
This includes adding the new TypoExpr-based lazy typo correction to
LookupMemberExprInRecord as an alternative to the existing eager typo
correction.
llvm-svn: 220698
Part of the infrastructure is a map from a TypoExpr to the Sema-specific
state needed to correct it, along with helpers to ease dealing with the
state.
The the typo count is propagated up the stack of
ExpressionEvaluationContextRecords when one is popped off of to
avoid accidentally dropping TypoExprs on the floor. For example,
the attempted correction of g() in test/CXX/class/class.mem/p5-0x.cpp
happens with an ExpressionEvaluationContextRecord that is popped off
the stack prior to ActOnFinishFullExpr being called and the tree
transform for TypoExprs being run.
llvm-svn: 220695
We build a NestedNameSpecifier that records the CXXRecordDecl in which
__super appeared. Name lookup is performed in all base classes of the
recorded CXXRecordDecl. Use of __super is allowed only inside class and
member function scope.
llvm-svn: 218484
Changes diagnostic options, language standard options, diagnostic identifiers, diagnostic wording to use c++14 instead of c++1y. It also modifies related test cases to use the updated diagnostic wording.
llvm-svn: 215982
Previously, assigning an inheritance model to a derived class would
trigger further assiginments to the various bases of the class. This
was done to fix a bug where we couldn't handle an implicit
base-to-derived conversion for pointers-to-members when the conversion
was ambiguous at an earlier point.
However, this is not how the MS scheme works. Instead, assign
inheritance models to *just* the class which owns to declaration we
ended up referencing.
N.B. This result is surprising in many ways. It means that it is
possible for a base to have a "larger" inheritance model than it's
derived classes. It also means that bases in the conversion path do not
get assigned a model.
struct A { void f(); void f(int); };
struct B : A {};
struct C : B {};
void f() { void (C::*x)() = &A::f; }
We can only begin to assign an inheritance model *after* we've seen the
address-of but *before* we've done the implicit conversion the more
derived pointer-to-member type. After that point, both 'A' and 'C' will
have an inheritance model but 'B' will not. Surprising, right?
llvm-svn: 215174
FunctionProtoType::ExtProtoInfo. Most of the users of these fields don't care
about the other ExtProtoInfo bits and just want to talk about the exception
specification.
llvm-svn: 214450
it through the normal TreeTransform logic for Exprs (which will strip off
implicit parts of the initialization and never re-create them).
llvm-svn: 213913
-- a constructor list initialization that unpacked an initializer list into
constructor arguments and
-- a list initialization that created as std::initializer_list and passed it
as the first argument to a constructor
in the AST. Use this flag while instantiating templates to provide the right
semantics for the resulting initialization.
llvm-svn: 213224
This patch implements semantic analysis to make sure that the loop is in OpenMP canonical form.
This is the form required for 'omp simd', 'omp for' and other loop pragmas.
Differential revision: http://reviews.llvm.org/D3778
llvm-svn: 210095
http://llvm.org/bugs/show_bug.cgi?id=19876
The following C++1y code results in a crash:
struct X {
int m = 10;
int n = [this](auto) { return m; }(20);
};
When implicitly instantiating the generic lambda's call operator specialization body, Sema is unable to determine the current 'this' type when transforming the MemberExpr 'm' - since it looks for the nearest enclosing FunctionDeclDC - which is obviously null.
I considered two ways to fix this:
1) In InstantiateFunctionDefinition, when the context is saved after the lambda scope info is created, retain the 'this' pointer.
2) Teach getCurrentThisType() to recognize it is within a generic lambda within an NSDMI/default-initializer and return the appropriate this type.
I chose to implement #2 (though I confess I do not have a compelling reason for choosing it over #1).
Richard Smith accepted the patch:
http://reviews.llvm.org/D3935
Thank you!
llvm-svn: 209874
Summary:
Naming the destructor using a typedef-name for the class-name is
well-formed.
This fixes PR19620.
Reviewers: rsmith, doug.gregor
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3583
llvm-svn: 209319
caused us to perform copy-initialization for the parameters of an allocation
function called by a new-expression multiple times, resulting in us rejecting
allocations that passed non-copyable parameters (and much worse things in
MSVC compat mode, where we potentially called this function multiple times).
llvm-svn: 208724
We accept 'void *p; p->~void();' for MSVC compatibility since r148682.
However, we were returning ExprError, rather than producing an AST,
despite only diagnosing it with a warning. CodeGen noticed that the
template function specialization had an invalid AST, and therefore
didn't generate code for it. This change makes us produce an AST with a
void pseudo-dtor call.
Part of PR18256.
llvm-svn: 207771
temporary in a decltype expression only applies if that temporary was created
by a function call, not by a function-style cast or other flavour of
expression.
llvm-svn: 201542
type-dependent variable, even if the initializer isn't value-dependent. This
happens for ParenListExprs composed of non-value-dependent subexpressions, for
instance.
We should really give ParenListExprs (and InitListExprs) the type of the
initialized entity if they're used to represent a dependent initialization (and
if so, set them to be type-, value- and instantiation-dependent).
llvm-svn: 200954
redeclaration, not just when looking them up for a use -- we need the implicit
declaration to appropriately check various properties of them (notably, whether
they're deleted).
llvm-svn: 200729
