[PATCH] D53847: [C++2a] P0634r3: Down with typename!

[Nicolas Lesser via Phabricator via cfe-commits]

Rakete1111 marked 9 inline comments as done.
Rakete1111 added a comment.

I also found another diagnostic regression:

  template <typename T>
  T::type();

The previous error message was something with "nested name specifier does not refer to class ...". Now, the T::type part is interpreted as type and so we get a "expected unqualified-id" error message.



================
Comment at: include/clang/Parse/Parser.h:2119
       DeclSpecContext DSC = DeclSpecContext::DSC_normal,
-      LateParsedAttrList *LateAttrs = nullptr);
+      LateParsedAttrList *LateAttrs = nullptr) {
+    return ParseDeclarationSpecifiers(DS, TemplateInfo, AS, DSC, LateAttrs,
----------------
This overload is unnecessary; I accidentally included it. I'll change it later so that Phab doesn't lose the review comments.


================
Comment at: include/clang/Parse/Parser.h:2054
+    case DeclSpecContext::DSC_template_param:
+    case DeclSpecContext::DSC_template_type_arg:
+    case DeclSpecContext::DSC_normal:
----------------
rsmith wrote:
> This doesn't seem right to me. Doesn't this mean that `X<T::U>` will change from being a non-type template argument to being a type template argument?
> 
> Maybe that's a bug in the wording paper, though, since that context *is* a /type-id/.
AFAIK no it won't, but I can't really tell if that's the right behavior or not. This patch doesn't touch the `X<T::U>` case.


================
Comment at: test/SemaCXX/unknown-type-name.cpp:121-122
 template<typename T>
-A<T>::g() { } // expected-error{{requires a type specifier}}
+A<T>::g() { } // expected-error{{expected unqualified-id}}
+// expected-warning at -1{{implicit 'typename' is a C++2a extension}}
----------------
rsmith wrote:
> rsmith wrote:
> > This is a diagnostic quality regression. Perhaps that's an inevitable consequence of P0634, but we should at least try to do better.
> This is marked "done" but doesn't seem to be done?
Oops, don't know why I did that. I can't figure out a way to fix this. I can implement a basic heuristic to detect some very basic cases like this one, but I don't think it's worth it.


Repository:
  rC Clang

https://reviews.llvm.org/D53847