(e.g. due to a broken template argument) following template parameters.

Fixes rdar://problem/8254267

llvm-svn: 109853

for AST nodes that aren't actually out-of-line (i.e., require a
nested-name-specifier). Fixes <rdar://problem/8204126>.

llvm-svn: 109704

rebuilder, i.e., remove a silly short-sighted hack from long
ago. Thanks to Abramo Bagnara for the test case/bug report!

llvm-svn: 109583

dependent bases, construct a dependent nested-name-specifier rather
than complaining that the name could not be found within the current
instantiation itself. Fixes PR7725.

llvm-svn: 109582

llvm-svn: 109532

dependent size.

llvm-svn: 109356

expression such as the "foo" in "this->blah.foo<1, 2>", and we can't
look into the type of "this->blah" (e.g., because it is dependent),
look into the local scope of a template of the same name. Fixes
<rdar://problem/8198511>.

llvm-svn: 108531

definition, we're likely going to end up breaking the invariants of
the template system, e.g., that the depths of template parameter lists
match up with the nesting template of the template. So, make sure we
mark such ill-formed declarations as invalid or don't even build them
at all.

llvm-svn: 108372

This flag and warning match GCC semantics. Also, move it to -Wextra as this is
a largely cosmetic issue and doesn't seem to mask problems. Subsequent fixes to
the tests which no longer by default emit the warning. Added explicit test
cases for both C and C++ behavior with the warning turned on.

llvm-svn: 108325

don't include the nested-name-specifier or template arguments: they
were only relevant when resolving the declaration. Fixes PR7460.

llvm-svn: 108235

strip cv-qualifiers from the expression's type when the language calls
for it: in C, that's all the time, while C++ only does it for
non-class types. 

Centralized the computation of the call expression type in
QualType::getCallResultType() and some helper functions in other nodes
(FunctionDecl, ObjCMethodDecl, FunctionType), and updated all relevant
callers of getResultType() to getCallResultType().

Fixes PR7598 and PR7463, along with a bunch of getResultType() call
sites that weren't stripping references off the result type (nothing
stripped cv-qualifiers properly before this change).

llvm-svn: 108234

class templates within class scope (which is ill-formed), and recover
by dropping the explicit specialization entirely. Fixes the infinite
loop in PR7622.

llvm-svn: 108217

int test1() {
  return;
}

default to an error.

llvm-svn: 108108

default arguments to template parameters don't have a DeclContext when
instantiated, and so we can't detect that we're in an instantiation context as
opposed to the definition context. However, it fixes the more commonly-occuring
cases in TMP code that use devolve to this type of tautology after
substitution.

llvm-svn: 108044

a template, be sure to include the template arguments from the
injected-class-name. Fixes PR7587.

llvm-svn: 107895

type so that it actually complains about the element type itself.

llvm-svn: 107299

llvm-svn: 107153

current attribute system, but it is enough to handle class templates which
specify parts of their alignment in terms of their template parameters.

This also replaces the attributes test in SemaTemplate with one that actually
tests working attributes instead of broken ones. I plan to add more tests here
for non-dependent attributes in a subsequent patch.

Thanks to John for walking me through some of this. =D

llvm-svn: 106818

PR7405, patch by Kyle Lippincott!

llvm-svn: 106523

attribute as part of the calculation. Sema::MarkDeclReferenced(), and
a few other places, want only to consider the "used" bit to determine,
e.g, whether to perform template instantiation. Fixes a linkage issue
with Boost.Serialization.

llvm-svn: 106252

template specialization type, copy the location information but use
the new type. Fixes PR7385.

llvm-svn: 106224

(or operator-function-id) as a template, but the context is actually
non-dependent or the current instantiation, allow us to use knowledge
of what kind of template it is, e.g., type template vs. function
template, for further syntactic disambiguation. This allows us to
parse properly in the presence of stray "template" keywords, which is
necessary in C++0x and it's good recovery in C++98/03.

llvm-svn: 106167

disambiguation keywords outside of templates in C++98/03. Previously,
the warning would fire when the associated nested-name-specifier was
not dependent, but that was a misreading of the C++98/03 standard:
now, we complain only when we're outside of any template.

llvm-svn: 106161

template name that refers to such a parameter. It's amazing that this
problem didn't surface earlier. Fixes PR7387.

llvm-svn: 106147

llvm-svn: 106111

virtual base class, but the class still has dependent base classes,
then don't diagnose the failed match as an error: the right base class
might magically appear. Fixes PR7259.

llvm-svn: 106103

non-dependent type or template name, respectively, in C++98/03. Fixes
PR7111 and <rdar://problem/8002682>.

llvm-svn: 105968

llvm-svn: 105818

expression, "forget" about the object type; only the
nested-name-specifier matters for name lookup purposes. Fixes PR7239.

llvm-svn: 104834

instantiation of a dependent elaborated type specifier.  Fixes PR 7199.

llvm-svn: 104822

any arguments that are default-argument expressions. The can show up
when we have a new expression whose constructor arguments are not
type-dependent and whose allocated type is not dependent and has a
constructor with default arguments. Fixes PR7202.

llvm-svn: 104690

promotion. Fixes <rdar://problem/8020920>.

llvm-svn: 104545

llvm-svn: 104445

in several important ways:

  - VLAs of non-POD types are not permitted.
  - VLAs cannot be used in conjunction with C++ templates.

These restrictions are intended to keep VLAs out of the parts of the
C++ type system where they cause the most trouble. Fixes PR5678 and
<rdar://problem/8013618>.

llvm-svn: 104443

the required "template" keyword, using the same heuristics we do for
dependent template names in member access expressions, e.g.,

test/SemaTemplate/dependent-template-recover.cpp:11:8: error: use 'template'
      keyword to treat 'getAs' as a dependent template name
    T::getAs<U>();
       ^
       template 

Fixes PR5404.

llvm-svn: 104409

that is missing the 'template' keyword, e.g., 

  t->getAs<T>()

where getAs is a member of an unknown specialization. C++ requires
that we treat "getAs" as a value, but that would fail to parse since T
is the name of a type. We would then fail at the '>', since a type
cannot be followed by a '>'.

This is a very common error for C++ programmers to make, especially
since GCC occasionally allows it when it shouldn't (as does Visual
C++). So, when we are in this case, we use tentative parsing to see if
the tokens starting at "<" can only be parsed as a template argument
list. If so, we produce a diagnostic with a fix-it that states that
the 'template' keyword is needed:

test/SemaTemplate/dependent-template-recover.cpp:5:8: error: 'template' keyword
      is required to treat 'getAs' as a dependent template name
    t->getAs<T>();
       ^
       template 

This is just a start of this patch; I'd like to apply the same
approach to everywhere that a template-id with dependent template name
can be parsed.

llvm-svn: 104406

be sure to merge its parameter scope with its parent's scope. Fixes
PR7184.

llvm-svn: 104386

sure that the anonymous struct/union record declaration gets
instantiated before the variable declaration, and that it and its
fields (recursively) get entries in the local instantiation map. Fixes
PR7088.

llvm-svn: 104305

llvm-svn: 104121

way regardless of whether some overloaded operator functions were
found by name lookup within the template. Fixes PR6851.

llvm-svn: 104107