Fix parsing of type-specifier-seq's. Types are syntactically allowed to be

defined here, but not semantically, so

  new struct S {};

is always ill-formed, even if there is a struct S in scope.

We also had a couple of bugs in ParseOptionalTypeSpecifier caused by it being
under-loved (due to it only being used in a few places) so merge it into
ParseDeclarationSpecifiers with a new DeclSpecContext. To avoid regressing, this
required improving ParseDeclarationSpecifiers' diagnostics in some cases. This
also required teaching ParseSpecifierQualifierList about constexpr... which
incidentally fixes an issue where we'd allow the constexpr specifier in other
bad places.


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

1 files changed, 20 insertions, 0 deletions

diff --git a/test/Parser/cxx11-type-specifier.cpp b/test/Parser/cxx11-type-specifier.cpp
new file mode 100644
index 0000000000..2e629f3ab5
--- /dev/null
+++ b/test/Parser/cxx11-type-specifier.cpp
@@ -0,0 +1,20 @@
+// RUN: %clang_cc1 -verify %s -std=c++11 -fcxx-exceptions
+
+// Tests for parsing of type-specifier-seq
+
+struct S {
+  operator constexpr int(); // expected-error{{type name does not allow constexpr}}
+};
+enum E { e };
+
+void f() {
+  try {
+    (void) new constexpr int; // expected-error{{type name does not allow constexpr}}
+  } catch (constexpr int) { // expected-error{{type name does not allow constexpr}}
+  }
+
+  // These parse as type definitions, not as type references with braced
+  // initializers. Sad but true...
+  (void) new struct S {}; // expected-error{{'S' can not be defined in a type specifier}}
+  (void) new enum E { e }; // expected-error{{'E' can not be defined in a type specifier}}
+}