For 'x::template y', consistently give a "no member named 'y' in 'x'"
diagnostic if there is no such member, and give a 'template keyword not
followed by a template' name error if there is such a member but it's not a
template. In the latter case, add a note pointing at the non-template.
Don't suggest inserting a 'template' keyword in 'X::Y<' if X is dependent
if the lookup of X::Y was actually not a dependent lookup and found only
non-templates.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332076 91177308-0d34-0410-b5e6-96231b3b80d8
This is the 5th Lit test patch.
Expanded expected diagnostics to vary by C++ dialect.
Expanded RUN line to: default, C++98/03 and C++11.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@255196 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127037 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@109582 91177308-0d34-0410-b5e6-96231b3b80d8
(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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@106167 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@106161 91177308-0d34-0410-b5e6-96231b3b80d8
non-dependent type or template name, respectively, in C++98/03. Fixes
PR7111 and <rdar://problem/8002682>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105968 91177308-0d34-0410-b5e6-96231b3b80d8
entering the current instantiation. Set up a little to preserve type location
information for typename types while we're in there.
Fixes a Boost failure.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102673 91177308-0d34-0410-b5e6-96231b3b80d8
propagating error conditions out of the various annotate-me-a-snowflake
routines. Generally (but not universally) removes redundant diagnostics
as well as, you know, not crashing on bad code. On the other hand,
I have just signed myself up to fix fiddly parser errors for the next
week. Again.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97221 91177308-0d34-0410-b5e6-96231b3b80d8
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91446 91177308-0d34-0410-b5e6-96231b3b80d8
nested-name-specifiers so that they don't gobble the template name (or
operator-function-id) unless there is also a
template-argument-list. For example, given
T::template apply
we would previously consume both "template" and "apply" as part of
parsing the nested-name-specifier, then error when we see that there
is no "<" starting a template argument list. Now, we parse such
constructs tentatively, and back off if the "<" is not present. This
allows us to parse dependent template names as one would use them for,
e.g., template template parameters:
template<typename T, template<class> class X = T::template apply>
struct MetaSomething;
Also, test default arguments for template template parameters.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86841 91177308-0d34-0410-b5e6-96231b3b80d8
nested name specifiers. Now we emit stuff like:
t.cpp:8:13: error: unknown type name 'X'
static foo::X P;
~~~~ ^
instead of:
t.cpp:8:16: error: invalid token after top level declarator
static foo::X P;
^
This is inspired by a really awful error message I got from
g++ when I misspelt diag::kind as diag::Kind.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69086 91177308-0d34-0410-b5e6-96231b3b80d8
failures that involve malformed types, e.g., "typename X::foo" where
"foo" isn't a type, or "std::vector<void>" that doens't instantiate
properly.
Similarly, be a bit smarter in our handling of ambiguities that occur
in Sema::getTypeName, to eliminate duplicate error messages about
ambiguous name lookup.
This eliminates two XFAILs in test/SemaCXX, one of which was crying
out to us, trying to tell us that we were producing repeated error
messages.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68251 91177308-0d34-0410-b5e6-96231b3b80d8
within nested-name-specifiers, e.g., for the "apply" in
typename MetaFun::template apply<T1, T2>::type
At present, we can't instantiate these nested-name-specifiers, so our
testing is sketchy.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68081 91177308-0d34-0410-b5e6-96231b3b80d8
class members to the corresponding in-class declaration.
Diagnose the erroneous use of 'static' on out-of-line definitions of
class members.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66740 91177308-0d34-0410-b5e6-96231b3b80d8
std::vector<int>::allocator_type
When we parse a template-id that names a type, it will become either a
template-id annotation (which is a parsed representation of a
template-id that has not yet been through semantic analysis) or a
typename annotation (where semantic analysis has resolved the
template-id to an actual type), depending on the context. We only
produce a type in contexts where we know that we only need type
information, e.g., in a type specifier. Otherwise, we create a
template-id annotation that can later be "upgraded" by transforming it
into a typename annotation when the parser needs a type. This occurs,
for example, when we've parsed "std::vector<int>" above and then see
the '::' after it. However, it means that when writing something like
this:
template<> class Outer::Inner<int> { ... };
We have two tokens to represent Outer::Inner<int>: one token for the
nested name specifier Outer::, and one template-id annotation token
for Inner<int>, which will be passed to semantic analysis to define
the class template specialization.
Most of the churn in the template tests in this patch come from an
improvement in our error recovery from ill-formed template-ids.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65467 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith