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
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
which is a common idiom to improve PIC'ness of code using the addr of
label extension. This implementation is a gross hack, but the only other
alternative would be to teach evalutate about this horrid combination.
While GCC allows things like "&&foo - &&bar + 1", people don't use this
in practice. This implements PR5131.
llvm-svn: 83957
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
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
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
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
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
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
Anders Carlsson