diff options
author | Douglas Gregor <dgregor@apple.com> | 2010-01-13 17:31:36 +0000 |
---|---|---|
committer | Douglas Gregor <dgregor@apple.com> | 2010-01-13 17:31:36 +0000 |
commit | 9de54ea41bdcf97f238ba9c4a1fa1d091d5813d9 (patch) | |
tree | cba2865d8d63cf45bf9270ea576c1e68bd757a88 /clang/test/SemaTemplate/injected-class-name.cpp | |
parent | b89b99f1f267237d68712b728b4aa5c90907cb48 (diff) | |
download | bcm5719-llvm-9de54ea41bdcf97f238ba9c4a1fa1d091d5813d9.tar.gz bcm5719-llvm-9de54ea41bdcf97f238ba9c4a1fa1d091d5813d9.zip |
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.
llvm-svn: 93322
Diffstat (limited to 'clang/test/SemaTemplate/injected-class-name.cpp')
-rw-r--r-- | clang/test/SemaTemplate/injected-class-name.cpp | 6 |
1 files changed, 1 insertions, 5 deletions
diff --git a/clang/test/SemaTemplate/injected-class-name.cpp b/clang/test/SemaTemplate/injected-class-name.cpp index 1a65aeb3d6c..482eae14ba5 100644 --- a/clang/test/SemaTemplate/injected-class-name.cpp +++ b/clang/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: |