what we found when we looked into <blah>", where <blah> is a
DeclContext*. We can now format DeclContext*'s in nice ways, e.g.,
"namespace N", "the global namespace", "'class Foo'".

This is part of PR3990, but we're not quite there yet.

llvm-svn: 84028

specialization. This completes C++ [temp.expl.spec]!

llvm-svn: 83980

template as a specialization. For example, this occurs with:

  template<typename T>
  struct X {
    template<typename U> struct Inner { /* ... */ };
  };

  template<> template<typename T>
  struct X<int>::Inner {
    T member;
  };

We need to treat templates that are member specializations as special
in two contexts:

  - When looking for a definition of a member template, we look
    through the instantiation chain until we hit the primary template
    *or a member specialization*. This allows us to distinguish
    between the primary "Inner" definition and the X<int>::Inner
    definition, above.
  - When computing all of the levels of template arguments needed to
    instantiate a member template, don't add template arguments
    from contexts outside of the instantiation of a member
    specialization, since the user has already manually substituted
    those arguments.

Fix up the existing test for p18, which was actually wrong (but we
didn't diagnose it because of our poor handling of member
specializations of templates), and add a new test for member
specializations of templates.

llvm-svn: 83974

function templates.

This commit ensures that friend function templates are constructed as
FunctionTemplateDecls rather than partial FunctionDecls (as they
previously were). It then implements template instantiation for friend
function templates, injecting the friend function template only when
no previous declaration exists at the time of instantiation. 

Oh, and make sure that explicit specialization declarations are not
friends.

llvm-svn: 83970

about the reason, rdar://7186119.

llvm-svn: 83940

that the scope in which it is being declared is complete. Also, when
instantiating a member class template's ClassTemplateDecl, be sure to
delay type creation so that the resulting type is dependent. Ick.

llvm-svn: 83923

that are declarations (rather than definitions). Also, be sure to set
the access specifiers properly when instantiating the declarations of
member function templates.

llvm-svn: 83911

llvm-svn: 83910

conditions.  Add a fixit to insert the parentheses.  Also fix a very minor
possible memory leak in 'for' conditions.

Fixes PR 4876 and rdar://problem/7289172

llvm-svn: 83907

instantiation has already been required. To do so, keep track of the
point of instantiation for anything that can be instantiated.

llvm-svn: 83890

wip - To prune excessive reporting.

llvm-svn: 83889

user-defined type conversions, issue list of ambiguites in addition 
to the diagnostic. So, clang now issues the following:

b.cpp:19:19: error: left hand operand to ->* must be a pointer to class compatible with the right hand operand, but is 'struct C1'
        int i = c1->*pmf;
                ~~^
b.cpp:19:19: note: because of ambiguity in conversion of 'struct C1' to 'struct E *'
b.cpp:5:5: note: candidate function
    operator E*();
    ^
b.cpp:11:5: note: candidate function
    operator E*();
    ^

llvm-svn: 83862

llvm-svn: 83766

Along the way, use RequireCompleteType when testing exception spec types.
Separate all the ugly spec stuff into its own file.

llvm-svn: 83764

Implement the core checking for compatible exception specifications in assignment and initialization.

The exception specification of the assignee must be the same or a subset of the target. In addition, exception specifications on arguments and return types must be equivalent, but this is not implemented yet.
This currently produces two diagnostics for every invalid assignment/initialization, due to the diagnostic produced outside PerformImplicitConversion, e.g. in CheckSingleInitializer. I don't know how to suppress this; in any case I think it is the wrong place for a diagnostic, since there are other diagnostics produced inside the function. So I'm leaving it as it is for the moment.

llvm-svn: 83710

Split the various ambiguous result enumerators into their own enum.  Tests
for most of C++ [namespace.qual].

llvm-svn: 83700

llvm-svn: 83694

Add CheckCallReturnType and start using it for regular call expressions. This will improve error messages. For 

struct B;

B f();

void g() {
f();
}

We now get

t.cpp:6:3: error: calling 'f' with incomplete return type 'struct B'
  f();
  ^~~
t.cpp:3:3: note: 'f' declared here
B f();
  ^
t.cpp:1:8: note: forward declaration of 'struct B'
struct B;
       ^

llvm-svn: 83692

llvm-svn: 83686

llvm-svn: 83685

  - Filter out unnamed declarations
  - Filter out declarations whose names are reserved for the
  implementation (e.g., __bar, _Foo) 
  - Place OVERLOAD: or COMPLETION: at the beginning of each
  code-completion result, so we can easily separate them from other
  compilation results.

llvm-svn: 83680

pass a LookupResult reference to lookup routines.  Call out uses which assume a single
result.

llvm-svn: 83674

injected-class-name (e.g., when we're referring to other
specializations of the current class template). Make sure that we see
the template rather than the injected-class-name. Fixes PR4768.

llvm-svn: 83672

Now we produce things like:
bug1.cpp:21:11: error: use of overloaded operator '->*' is ambiguous
        int i = c->*pmf;        // expected-error {{use of overloaded operator '->*' is ambiguous}} \
                ~^  ~~~
bug1.cpp:21:11: note: built-in candidate operator ->* ('struct A volatile *', 'int const struct A::*')
bug1.cpp:21:11: note: built-in candidate operator ->* ('struct A volatile *', 'int restrict struct A::*')
...

Still need to look at an issue (indicated as FIXME in the test case).

llvm-svn: 83650

operator's types.

llvm-svn: 83648

I still don't like it but it is improvement over what we had.

llvm-svn: 83603

- Fixup SortCodeCompleteResult() to properly sort keywords on Mac OS (compare was system dependent). Worked on Linux, failed on Mac OS (which caused the recently added testcase to fail on Linux). 
- Sort results in testcase.

llvm-svn: 83597

because of missing default constructor of a member.
Fixes pr5154.

llvm-svn: 83583

llvm-svn: 83582

llvm-svn: 83579

llvm-svn: 83577

Also, eliminate a redundant diagnostic by marking a variable declared
with incomplete type as an invalid declaration.

llvm-svn: 83553

function and member function templates that are not definitions. Add
more tests to ensure that explicit specializations of member function
templates prevent instantiation.

llvm-svn: 83550

templates, and keep track of how those member classes were
instantiated or specialized. 

Make sure that we don't try to instantiate an explicitly-specialized
member class of a class template, when that explicit specialization
was a declaration rather than a definition.

llvm-svn: 83547

track of the kind of specialization or instantiation. Also, check the
scope of the specialization and ensure that a specialization
declaration without an initializer is not a definition.

llvm-svn: 83533

template instantiation of a member function of a class template.
FIXME -= 2;

llvm-svn: 83520

specialization kind is TSK_ImplicitInstantiation. Previously, we would
end up implicitly instantiating functions that had explicit
specialization declarations or explicit instantiation declarations
(with no corresponding definitions).

llvm-svn: 83511

function of a class template was implicitly instantiated, explicitly
instantiated (declaration or definition), or explicitly
specialized. The same MemberSpecializationInfo structure will be used
for static data members and member classes as well.

llvm-svn: 83509

Don't create a new declaration for friend classes if a declaration already exists.

llvm-svn: 83505

templates. Previously, these weren't handled as specializations at
all. The AST for representing these as specializations is still a work
in progress.

llvm-svn: 83498