explicit specialization to a warning for C++98 mode (this is a defect report
resolution, so per our informal policy it should apply in C++98), and turn
the warning on by default for C++11 and later. In all cases where it fires, the
right thing to do is to remove the pointless explicit instantiation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280308 91177308-0d34-0410-b5e6-96231b3b80d8
the right namespace in C++11 mode. Teach the code to prefer the 'must be in
precisely this namespace' diagnostic whenever that's true, and fix a defect
which resulted in the -Wc++11-compat warning in C++98 mode sometimes being
omitted.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@142329 91177308-0d34-0410-b5e6-96231b3b80d8
explicit instantiations of template. C++0x clarifies the intent
(they're ill-formed in some cases; see [temp.explicit] for
details). However, one could squint at the C++98/03 standard and
conclude they are permitted, so reduce the error to a warning
(controlled by -Wc++0x-compat) in C++98/03 mode.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103482 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
complaint to a warning and providing a helpful node in the case where
the "template<>" header is redundant because the corresponding
template-id refers to an explicit specialization. C++0x might still
change this behavior, and existing practice is all over the place on
the number of "template<>" headers actually needed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89651 91177308-0d34-0410-b5e6-96231b3b80d8
template, introduce that member function into the template
instantiation stack. Also, add diagnostics showing the member function
within the instantiation stack and clean up the qualified-name
printing so that we get something like:
note: in instantiation of member function 'Switch1<int, 2, 2>::f'
requested here
in the template instantiation backtrace.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72015 91177308-0d34-0410-b5e6-96231b3b80d8
template<typename T>
struct X {
struct Inner;
};
template struct X<int>::Inner;
This change is larger than it looks because it also fixes some
a problem with nested-name-specifiers and tags. We weren't requiring
the DeclContext associated with the scope specifier of a tag to be
complete. Therefore, when looking for something like "struct
X<int>::Inner", we weren't instantiating X<int>.
This, naturally, uncovered a problem with member pointers, where we
were requiring the left-hand side of a member pointer access
expression (e.g., x->*) to be a complete type. However, this is wrong:
the semantics of this expression does not require a complete type (EDG
agrees).
Stuart vouched for me. Blame him.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71756 91177308-0d34-0410-b5e6-96231b3b80d8
of class members (recursively). Only member classes are actually
instantiated; the instantiation logic for member functions and
variables are just stubs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71713 91177308-0d34-0410-b5e6-96231b3b80d8
templates. In particular:
- An explicit instantiation can follow an implicit instantiation (we
were improperly diagnosing this as an error, previously).
- In C++0x, an explicit instantiation that follows an explicit
specialization of the same template specialization is ignored. In
C++98, we just emit an extension warning.
- In C++0x, an explicit instantiation must be in a namespace
enclosing the original template. C++98 has no such requirement.
Also, fixed a longstanding FIXME regarding the integral type that is
used for the size of a constant array type when it is being instantiated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71689 91177308-0d34-0410-b5e6-96231b3b80d8
still aren't instantiating the definitions of class template members,
and core issues 275 and 259 will both affect the checking that we do
for explicit instantiations (but are not yet implemented).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71613 91177308-0d34-0410-b5e6-96231b3b80d8
template class X<int>;
This also cleans up the propagation of template information through
declaration parsing, which is used to improve some diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71608 91177308-0d34-0410-b5e6-96231b3b80d8
Charles Li