Reimplement constructor declarator parsing to cope with template-ids

that name constructors, the endless joys of out-of-line constructor
definitions, and various other corner cases that the previous hack
never imagined. Fixes PR5688 and tightens up semantic analysis for
constructor names.

Additionally, fixed a problem where we wouldn't properly enter the
declarator scope of a parenthesized declarator. We were entering the
scope, then leaving it when we saw the ")"; now, we re-enter the
declarator scope before parsing the parameter list.

Note that we are forced to perform some tentative parsing within a
class (call it C) to tell the difference between

  C(int); // constructor

and

  C (f)(int); // member function

which is rather unfortunate. And, although it isn't necessary for
correctness, we use the same tentative-parsing mechanism for
out-of-line constructors to improve diagnostics in icky cases like:

  C::C C::f(int); // error: C::C refers to the constructor name, but
                  // we complain nicely and recover by treating it as
                  // a type.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93322 91177308-0d34-0410-b5e6-96231b3b80d8

1 files changed, 1 insertions, 5 deletions

diff --git a/test/SemaTemplate/injected-class-name.cpp b/test/SemaTemplate/injected-class-name.cpp
index 1a65aeb3d6..482eae14ba 100644
--- a/test/SemaTemplate/injected-class-name.cpp
+++ b/test/SemaTemplate/injected-class-name.cpp
@@ -11,11 +11,7 @@ struct X<int***> {
   typedef X<int***> *ptr;
 };
 
-// FIXME: EDG rejects this in their strict-conformance mode, but I
-// don't see any wording making this ill-formed.  Actually,
-// [temp.local]p2 might make it ill-formed. Are we "in the scope of
-// the class template specialization?"
-X<float>::X<int> xi = x;
+X<float>::X<int> xi = x; // expected-error{{qualified reference to 'X' is a constructor name rather than a template name wherever a constructor can be declared}}
 
 // [temp.local]p1: