function type. Educate template argument deduction thusly, fixing
PR9974 / <rdar://problem/9479155>.

llvm-svn: 131811

Also, don't reject alias templates in all ElaboratedTypes: some ElaboratedTypes do not correspond to elaborated-type-specifiers.

llvm-svn: 131342

also consider whether any of the parameter types (as written, prior to
decay) are dependent. Fixes PR9880 and <rdar://problem/9408413>.

llvm-svn: 131099

Patch for PR 7409 - only error on definition of invalid typedefs.  Suppress errors for additional uses of this invalid typedef.

llvm-svn: 131043

llvm-svn: 130953

template parameter of type 'bool', force the value to be zero or
one. Fixes <rdar://problem/9169404>.

llvm-svn: 130873

llvm-svn: 130775

parameters on the floor in certain cases:
class X {
  template <typename T> friend typename A<T>::Foo;
};

This was parsed as a *non* template friend declaration some how, and
received an ExtWarn. Fixing the parser to actually provide the template
parameters to the freestanding declaration parse triggers the code which
specifically looks for such constructs and hard errors on them.

Along the way, this prevents us from trying to instantiate constructs
like the above inside of a outer template. This is important as loosing
the template parameters means we don't have a well formed declaration
and template instantiation will be unable to rebuild the AST. That fixes
a crash in the GCC test suite.

llvm-svn: 130772

partial ordering of function templates, use a simple superset
relationship rather than the convertibility-implying
isMoreQualifiedThan/compatibilyIncludes relationship. Fixes partial
ordering between references and address-space-qualified references.

llvm-svn: 130612

non-CVR qualifiers. We can now properly match address-space--qualified
references during template argument deduction.

llvm-svn: 130365

deduction. The good news is that address spaces are a lot less broken
in this regard than I'd expected.

llvm-svn: 130346

in the classification of template names and using declarations. We now
properly typo-correct the leading identifiers in statements to types,
templates, values, etc. As an added bonus, this reduces the number of
lookups required for disambiguation.

llvm-svn: 130288

Make the invalid declarator recovery when parsing members work the same as when parsing global decls. It's still rather broken (skipping much too far when the declarator belongs to a function definition), but at least not so broken as to mismatch braces. Tested by the removal of the fixme in the template test case.

llvm-svn: 130101

dealing with address-space- and GC-qualified pointers. Previously,
these qualifiers were being treated just like cvr-qualifiers (in some
cases) or were completely ignored, leading to uneven behavior. For
example, const_cast would allow conversion between pointers to
different address spaces.

The new semantics are fairly simple: reinterpret_cast can be used to
explicitly cast between pointers to different address spaces
(including adding/removing addresss spaces), while
static_cast/dynamic_cast/const_cast do not tolerate any changes in the
address space. C-style casts can add/remove/change address spaces
through the reinterpret_cast mechanism. Other non-CVR qualifiers
(e.g., Objective-C GC qualifiers) work similarly.

As part of this change, I tweaked the "casts away constness"
diagnostic to use the term "casts away qualifiers". The term
"constness" actually comes from the C++ standard, despite the fact
that removing "volatile" also falls under that category. In Clang, we
also have restrict, address spaces, ObjC GC attributes, etc., so the
more general "qualifiers" is clearer.

llvm-svn: 129583

Detect when the string "<::" is found in code after a cast or template name and is interpreted as "[:" because of the digraph "<:". When found, give an error with a fix-it to add whitespace between the "<" and "::".

Patch by Richard Trieu! Plus a small tweak from me to deal with one of the tokens coming from a macro.

llvm-svn: 129540

and move a vector-splat check to follow l-value conversion.

llvm-svn: 129254

The idea is that you can create a VarDecl with an unknown type, or a
FunctionDecl with an unknown return type, and it will still be valid to
access that object as long as you explicitly cast it at every use.  I'm
still going back and forth about how I want to test this effectively, but
I wanted to go ahead and provide a skeletal implementation for the LLDB
folks' benefit and because it also improves some diagnostic goodness for
placeholder expressions.

llvm-svn: 129065

overload, so that we actually do the resolution for full expressions
and emit more consistent, useful diagnostics. Also fixes an IRGen
crasher, where Sema wouldn't diagnose a resolvable bound member
function template-id used in a full-expression (<rdar://problem/9108698>).

llvm-svn: 127747

should be resolvable, from Faisal Vali!

llvm-svn: 127521

unless we already know that it has a definition. Fixes
PR9449/<rdar://problem/9115785>.

llvm-svn: 127512

to set the source-location information for the template arguments to
the *transformed* source-location information, not the original
source-location information. Fixes <rdar://problem/8986308> (a libc++
SFINAE issue) and the Boost.Polygon failure.

llvm-svn: 127150

declaration because of interesting ordering dependencies while
instantiating a class template or member class thereof. Complain,
rather than asserting (+Asserts) or silently rejecting the code
(-Asserts).

Fixes the crash-on-invalid in PR8965. 

llvm-svn: 127129

template name as the result of substitution. The qualifier is handled
separately by the tree transformer, so we would end up in an
inconsistent state.

This is actually the last bit of PR9016, and possibly also fixes
PR8965. It takes Boost.Icl from "epic fail" down to a single failure.

llvm-svn: 127108

template (not a specialization!), use the "injected" function template
arguments, which correspond to the template parameters of the function
template. This is required when substituting into the default template
parameters of template template parameters within a function template.

Fixes PR9016.

llvm-svn: 127092

transform the type that replaces the template type parameter. In the
vast majority of cases, there's nothing to do, because most template
type parameters are replaced with something non-dependent that doesn't
need further transformation. However, when we're dealing with the
default template arguments of template template parameters, we might
end up replacing a template parameter (of the template template
parameter) with a template parameter of the enclosing template. 
 
This addresses part of PR9016, but not within function
templates. That's a separate issue.

llvm-svn: 127091

llvm-svn: 127042

to cope with non-type templates by providing appropriate
errors. Previously, we would either assert, crash, or silently build a
dependent type when we shouldn't. Fixes PR9226.

llvm-svn: 127037

DependentTemplateSpecializationType during tree transformation, retain
the NestedNameSpecifierLoc as it was used to translate the template
name, rather than reconstructing it from the template name.

Fixes PR9401.

llvm-svn: 127015

DeclContext once we've created it. This mirrors what we do for
function parameters, where the parameters start out with
translation-unit context and then are adopted by the appropriate
DeclContext when it is created. Also give template parameters public
access and make sure that they don't show up for the purposes of name
lookup.

Fixes PR9400, a regression introduced by r126920, which implemented
substitution of default template arguments provided in template
template parameters (C++ core issue 150).

How on earth could the DeclContext of a template parameter affect the
handling of default template arguments?

I'm so glad you asked! The link is
Sema::getTemplateInstantiationArgs(), which determines the outer
template argument lists that correspond to a given declaration. When
we're instantiating a default template argument for a template
template parameter within the body of a template definition (not it's
instantiation, per core issue 150), we weren't getting any outer
template arguments because the context of the template template
parameter was the translation unit. Now that the context of the
template template parameter is its owning template, we get the
template arguments from the injected-class-name of the owning
template, so substitution works as it should.

llvm-svn: 127004

parameter, save the instantiated default template arguments along with
the explicitly-specified template argument list. That way, we prefer
the default template template arguments corresponding to the template
template parameter rather than those of its template template argument.

This addresses the likely direction of C++ core issue 150, and fixes
PR9353/<rdar://problem/9069136>, bringing us closer to the behavior of
EDG and GCC.

llvm-svn: 126920

template specialization types. This also required some parser tweaks,
since we were losing track of the nested-name-specifier's source
location information in several places in the parser. Other notable
changes this required:

  - Sema::ActOnTagTemplateIdType now type-checks and forms the
    appropriate type nodes (+ source-location information) for an
    elaborated-type-specifier ending in a template-id. Previously, we
    used a combination of ActOnTemplateIdType and
    ActOnTagTemplateIdType that resulted in an ElaboratedType wrapped
    around a DependentTemplateSpecializationType, which duplicated the
    keyword ("class", "struct", etc.) and nested-name-specifier
    storage.

  - Sema::ActOnTemplateIdType now gets a nested-name-specifier, which
    it places into the returned type-source location information.

  - Sema::ActOnDependentTag now creates types with source-location
    information.

llvm-svn: 126808

a dependent template name rather than (indirectly and incorrectly)
trying to determine whether we can compute a context for the
nested-name-specifier. Fixes a GCC testsuite regression,
<rdar://problem/9068589>.

llvm-svn: 126749

llvm-svn: 126599

current instantiation, even though we have a RecordDecl describing
them. Fixes PR9255.

Amusingly, I've had this patch sitting around for a month or two
because it was "obviously" wrong, but hadn't gotten around to writing
a test case to submit the fix :)

llvm-svn: 126038

llvm-svn: 126037

diagnostics, resolving PR9227.

Patch originally by Mihai Rusu and Stephen Hines with some minimal style
tweaks from me.

llvm-svn: 125999

or union, place the qualifier on the outermost member reference
expression, which actually contains the entity name.

Fixes PR9188/<rdar://problem/8990184>.

llvm-svn: 125822

enumeration type, we were generating an integer literal implicitly
casted to the appropriate enumeration type. However, later checks on
that expression would strip the implicit cast.

This commit tweaks the lame hack, by creating an explicit cast instead
of an implicit cast. The right answer is to introduce a 
SubstNonTypeTemplateParmExpr expression that acts like the substituted
result. I'll investigate that soon.

llvm-svn: 125818

parameter type to see what's behind it, so that we don't end up
printing silly things like "float const *" when "const float *" would
make more sense. Also, replace the pile of "isa" tests with a simple
switch enumerating all of the cases, making a few more obvious cases
use prefix qualifiers.

llvm-svn: 125729

PR8626.

llvm-svn: 125506