[PATCH] D130511: [pseudo][wip] Eliminate simple-type-specifier ambiguities.

Haojian Wu via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Jul 26 01:59:29 PDT 2022


hokein added a comment.

In D130511#3677423 <https://reviews.llvm.org/D130511#3677423>, @sammccall wrote:

> My main concern here is that this might reject valid code (and if it doesn't, it's not obvious why).
> It does look like C++ forbids the cases I can come up with (e.g. trying to provide a definition for `::Foo` is rejected by clang with "definition or redeclaration of Foo cannot name the global scope).
> But I'd be way more comfortable if we could connect the specific guard rules here with spec language.

The qualified declarator is tricky (it was forbidden until https://cplusplus.github.io/CWG/issues/482.html).

The closest thing I can find in the standard is basic.lookup.qual.general <https://eel.is/c++draft/basic.lookup.qual.general>:

> If a name, template-id, or decltype-specifier is followed by a ​::​, it shall designate a namespace, class, enumeration, or dependent type, and the ​::​ is never interpreted as a complete nested-name-specifier.

IIUC, this rule forbids the parses `X::Y ::Z;` and `X ::Y::Z;` (because in the declarator we have a complete `::` nested-name-specifier).

> If we can't do this rigorously and merely are trying to encourage the *common* parse, then we should do it in soft disambig.
>
> I'd like to think about this some more, do you know what part of the spec says that `x ::y` is invalid if x is e.g. a typedef for `int`?

I didn't try to find it harder, I guess it is probably in the qualified-name-look-up section.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D130511/new/

https://reviews.llvm.org/D130511



More information about the cfe-commits mailing list