Commit Graph

14 Commits

Author SHA1 Message Date
Charles Li 9ea0817c5a [Test] Make Lit tests C++11 compatible #9
[Test] Make Lit tests C++11 compatible #9

Differential Revision: https://reviews.llvm.org/D20710

llvm-svn: 296184
2017-02-24 22:22:05 +00:00
Richard Smith e4caa48dbb DR259: Demote the pedantic error for an explicit instantiation after an
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.

llvm-svn: 280308
2016-08-31 23:23:25 +00:00
David Blaikie cc5f8f0d9e Switch to the C++11 warning flags in tests.
Patch by Ahmed Charles!

llvm-svn: 142340
2011-10-18 05:54:07 +00:00
Richard Smith 050d261ec7 Refactor the checking for explicit template instantiations being performed in
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.

llvm-svn: 142329
2011-10-18 02:28:33 +00:00
Douglas Gregor c97d7a2c6a The C++98/03 standard is disturbingly silent about out-of-scope
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.

llvm-svn: 103482
2010-05-11 17:39:34 +00:00
Daniel Dunbar 8fbe78f6fc Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.
- 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).

llvm-svn: 91446
2009-12-15 20:14:24 +00:00
Douglas Gregor 65911498ef Tolerate extraneous "template<>" headers better, downgrading the
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.

llvm-svn: 89651
2009-11-23 12:11:45 +00:00
Douglas Gregor e47f5a76cc Additional semantic checking for explicit template instantiations,
focusing on the scope- and qualifier-related semantic requirements in
C++ [temp.explicit]p2.

llvm-svn: 84154
2009-10-14 23:41:34 +00:00
Douglas Gregor 8567358cc9 When instantiating the definition of a member function of a class
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.

llvm-svn: 72015
2009-05-18 17:01:57 +00:00
Douglas Gregor 2ec748cd5a Implement explicit instantiations of member classes of class templates, e.g.,
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.

llvm-svn: 71756
2009-05-14 00:28:11 +00:00
Douglas Gregor bbbb02d463 Explicit instantiations of templates now instantiate the definitions
of class members (recursively). Only member classes are actually
instantiated; the instantiation logic for member functions and
variables are just stubs.

llvm-svn: 71713
2009-05-13 20:28:22 +00:00
Douglas Gregor f61eca93c0 Improve the semantic checking for explicit instantiations of
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.

llvm-svn: 71689
2009-05-13 18:28:20 +00:00
Douglas Gregor a1f4997368 Semantic analysis for explicit instantiation of class templates. We
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).

llvm-svn: 71613
2009-05-13 00:25:59 +00:00
Douglas Gregor 1b57ff32a8 Implement parsing for explicit instantiations of class templates, e.g.,
template class X<int>;

This also cleans up the propagation of template information through
declaration parsing, which is used to improve some diagnostics.

llvm-svn: 71608
2009-05-12 23:25:50 +00:00