This change partly addresses a heinous problem we have with the
parsing of attribute arguments that are a lone identifier. Previously,
we would end up parsing the 'align' attribute of this as an expression
"(Align)":
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align((Align)))) char storage[Size];
};
while this would parse as a "parameter name" 'Align':
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align(Align))) char storage[Size];
};
The code that handles the alignment attribute would completely ignore
the parameter name, so the while the first of these would do what's
expected, the second would silently be equivalent to
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align)) char storage[Size];
};
i.e., use the maximal alignment rather than the specified alignment.
Address this by sniffing the "Args" provided in the TableGen
description of attributes. If the first argument is "obviously"
something that should be treated as an expression (rather than an
identifier to be matched later), parse it as an expression.
Fixes <rdar://problem/13700933>.
llvm-svn: 180973
This change partly addresses a heinous problem we have with the
parsing of attribute arguments that are a lone identifier. Previously,
we would end up parsing the 'align' attribute of this as an expression
"(Align)":
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align((Align)))) char storage[Size];
};
while this would parse as a "parameter name" 'Align':
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align(Align))) char storage[Size];
};
The code that handles the alignment attribute would completely ignore
the parameter name, so the while the first of these would do what's
expected, the second would silently be equivalent to
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align)) char storage[Size];
};
i.e., use the maximal alignment rather than the specified alignment.
Address this by sniffing the "Args" provided in the TableGen
description of attributes. If the first argument is "obviously"
something that should be treated as an expression (rather than an
identifier to be matched later), parse it as an expression.
Fixes <rdar://problem/13700933>.
llvm-svn: 180970
are now two distinct canonical 'AutoType's: one is the undeduced 'auto'
placeholder type, and the other is a deduced-but-dependent type. All
deduced-to-a-non-dependent-type cases are still non-canonical.
llvm-svn: 180789
a dependent-scope id expression when a templated member function of a
non-templated class references an unknown identifier, since instantiation won't
rebuild it (and we can tell at parse time that it'll never work). Based on a
patch by Faisal Vali!
llvm-svn: 180701
When two template decls with the same name are used in this diagnostic,
force them to print their qualified names. This changes the bad message of:
candidate template ignored: could not match 'array' against 'array'
to the better message of:
candidate template ignored: could not match 'NS2::array' against 'NS1::array'
llvm-svn: 179056
* Give the right diagnostic for 'restrict' applied to a non-pointer, non-reference type.
* Don't reject 'restrict' applied indirectly to an Objective-C object pointer type (eg, through template instantiation).
llvm-svn: 178200
When Sema::RequireCompleteType() is given a class template
specialization type that then fails to instantiate, it returns
'true'. On subsequent invocations, it can return false. Make sure that
this difference doesn't change the result of
Sema::CompareReferenceRelationship, which is expected to remain stable
while we're checking an initialization sequence.
llvm-svn: 178088
template instantiation will still consider them to be definitions
if we instantiate the containing class before we get around
to parsing the friend.
This seems like a legitimate use of "late template parsed" to me,
but I'd appreciate it if someone responsible for the MS feature
would look over this.
This file already appears to access AST nodes directly, which
is arguably not kosher in the parser, but the performance of this
path matters enough that perpetuating the sin is justifiable.
Probably we ought to reconsider this policy for very simple
manipulations like this.
The reason this entire thing is necessary is that
function template instantiation plays some very gross games
in order to not associate an instantiated function template
with the class it came from unless it's a definition, and
the reason *that's* necessary is that the AST currently
cannot represent the instantiation history of individual
function template declarations, but instead tracks it in
common for the entire function template. That probably
prevents us from correctly reporting ill-formed calls to
ambiguously instantiated friend function templates.
rdar://12350696
llvm-svn: 177003
We were transforming the scope type of a pseudo-destructor expression
(e.g., the first T in x->T::~T()) as a freestanding type, which meant
that dependent template specialization types here would stay dependent
even when no template parameters were named. This would eventually
mean that a dependent expression would end up in what should be
fully-instantiated ASTs, causing IRgen to assert.
llvm-svn: 176723
designator" diagnostic with more correct and more human-friendly "cannot take
address of rvalue of type 'T'".
For the case of & &T::f, provide a custom diagnostic, rather than unhelpfully
saying "cannot take address of rvalue of type '<overloaded function type>'".
For the case of &array_temporary, treat it just like a class temporary
(including allowing it as an extension); the existing diagnostic wording
for the class temporary case works fine.
llvm-svn: 174262
have a direct mismatch between some component of the template and some
component of the argument. The diagnostic now says what the mismatch was, but
doesn't yet say which part of the template doesn't match.
llvm-svn: 174039
parameters (per C++ [temp.param]p8) when computing the type of a
reference to a non-type template parameter. Fixes <rdar://problem/13000548>.
llvm-svn: 172585
CXXScalarValueInitExpr (or an ImplicitValueInitExpr), strip it back down to an
empty pair of parentheses so that the initialization code can tell that we're
performing value-initialization.
llvm-svn: 170867
too). When instantiating a direct-initializer, if we find it has zero
arguments, produce an empty ParenListExpr rather than returning a null
expression.
llvm-svn: 170490
determine which member function would be the callee from within the template
definition, don't pass that function as a "non-member function" to
CreateOverloadedBinOp. Instead, just rely on it to select the member function
for itself.
llvm-svn: 168818
initialization, don't rebuild it. Remove a couple of hacks which were trying to
work around this. Fix the special case for one-argument CXXConstructExprs to
not apply if the one argument is a default argument.
llvm-svn: 168582
and we resolve it to a specific function based on the type which it's used as,
don't forget to mark it as referenced.
Fixes a regression introduced in r167514.
llvm-svn: 167918
would have diagnosed this at instantiation time anyway, if only we
didn't hang on all of these test cases. Fixes <rdar://problem/12629723>
llvm-svn: 167651
the base class. If the base class deduction succeeds, use those results. If
it fails, keep using the results from the derived class template deduction.
This prevents an assertion later where the type of deduction failure doesn't
match up with the template deduction info.
llvm-svn: 167550
instantiate it if it can be instantiated and implicitly define it if it can be
implicitly defined. This matches g++'s approach. Remove some cases from
SemaOverload which were marking functions as referenced when just planning how
overload resolution would proceed; such cases are not actually references.
llvm-svn: 167514
found: if an overloaded operator& is present before a template definition,
the expression &T::foo is represented as a CXXOperatorCallExpr, not as a
UnaryOperator, so we didn't notice that it's permitted to reference a non-static
data member of an unrelated class.
While investigating this, I discovered another problem in this area: we are
treating template default arguments as unevaluated contexts during substitution,
resulting in performing incorrect checks for uses of non-static data members in
C++11. That is not fixed by this patch (I'll look into this soon; it's related
to the failure to correctly instantiate constexpr function templates), but was
resulting in this bug not firing in C++11 mode (except with -Wc++98-compat).
Original message:
PR14124: When performing template instantiation of a qualified-id outside of a
class, diagnose if the qualified-id instantiates to a non-static class member.
llvm-svn: 166385
fatal error. Previously, if a fatal error was followed by a diagnostic which
was suppressed due to a SFINAETrap, we'd forget that we'd seen a fatal error.
llvm-svn: 164437
Douglas Gregor