Incorrect semantic error reported by clang++ when using "uint16_t" together with global namespace.

[lichenxuan87]

Source code and error message

Error message was reported by clang++ when compiling below source code:

#include <stdint.h>

class CLangTester {
 public:
    uint8_t test();
};

uint8_t ::CLangTester::test() {
    return 23;
}

int main() {
    CLangTester tester;
    tester.test();
    return 0;
}

Error message:

/usr/bin/clang++ -c -I/usr/local/include -I. -Wall -g -std=c++14 namespace.cpp -o build/namespace.o
namespace.cpp:21:1: error: 'uint8_t' (aka 'unsigned char') is not a class, namespace, or enumeration
uint8_t ::CLangTester::test() {
^
1 error generated.
make: *** [Makefile:28: build/namespace.o] Error 1

Passed when using g++

g++ -c -I/usr/local/include -I. -Wall -g -std=c++14 namespace.cpp -o build/namespace.o
g++ build/namespace.o -L/usr/local/lib -L/usr/lib -lrt -pthread -Wl,-rpath-link,/usr/lib,-rpath-link,/usr/local/lib  -o clang-namespace 

Version info

clang --version output:

clang version 10.0.0-4ubuntu1 
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

Additional info

The error disappears when I changed

uint8_t ::CLangTester::test() {

to

uint8_t CLangTester::test() {

Apparently the clang++ ignored the space between uint8_t and ::, while ::ClangTester is totally valid.

[safocl]

dcl.fct.def p1

Function definitions have the form
function-definition:
attribute-specifier-seq(opt) decl-specifier-seq(opt) declarator virt-specifier-seq opt function-body
attribute-specifier-seq(opt) decl-specifier-seq(opt) declarator requires-clause function-body

dcl.decl.general p5

declarator:
ptr-declarator
[...]

ptr-declarator:
noptr-declarator
[...]

noptr-declarator:
declarator-id attribute-specifier-seq(opt)
noptr-declarator parameters-and-qualifiers

declarator-id:
...(opt) id-expression

expr.prim.id.general

id-expression:
[...]
qualified-id

expr.prim.id.qual

qualified-id:
nested-name-specifier template(opt) unqualified-id

nested-name-specifier:
::
[...]

that is, the name of a class method in the definition may contain the "::" sign in front.

[safocl]

dcl.fct.def.general p3:

[Example 1: A simple example of a complete function definition is
int max(int a, int b, int c) {
int m = (a > b) ? a : b;
return (m > c) ? m : c;
}
Here int is the decl-specifier-seq; max(int a, int b, int c) is the declarator; { /* ... */ } is the function-body.
— end example]

[safocl]

How should this be parsed?

struct ItIsType{};

struct Typer {
    using ItIsType = ::ItIsType;
};

class CLangTester {
 public:
    ::Typer::ItIsType test();
};

::Typer::ItIsType ::CLangTester::test() {
    return {};
}

https://godbolt.org/z/5TK7f6va8
:)

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Peter Lee (lichenxuan87)

### Source code and error message Error message was reported by clang++ when compiling below source code: ``` #include <stdint.h>

class CLangTester {
public:
uint8_t test();
};

uint8_t ::CLangTester::test() {
return 23;
}

int main() {
CLangTester tester;
tester.test();
return 0;
}

Error message:

/usr/bin/clang++ -c -I/usr/local/include -I. -Wall -g -std=c++14 namespace.cpp -o build/namespace.o
namespace.cpp:21:1: error: 'uint8_t' (aka 'unsigned char') is not a class, namespace, or enumeration
uint8_t ::CLangTester::test() {
^
1 error generated.
make: *** [Makefile:28: build/namespace.o] Error 1

Passed when using g++

g++ -c -I/usr/local/include -I. -Wall -g -std=c++14 namespace.cpp -o build/namespace.o
g++ build/namespace.o -L/usr/local/lib -L/usr/lib -lrt -pthread -Wl,-rpath-link,/usr/lib,-rpath-link,/usr/local/lib -o clang-namespace

### Version info
clang --version output:

clang version 10.0.0-4ubuntu1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

### Additional info
The error disappears when I changed 

uint8_t ::CLangTester::test() {

to 

uint8_t CLangTester::test() {

Apparently the clang++ ignored the space between `uint8_t` and `::`, while `::ClangTester` is totally valid.
</details>

[zygoloid]

The relevant rule is [basic.loolup.qual.general]/1:

If a name, template-id, or computed-type-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.

So clang is correct to reject this -- though the diagnostic could be better, especially when there's a space before the ::.

[safocl]

The relevant rule is [basic.loolup.qual.general]/1:

If a name, template-id, or computed-type-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.

So clang is correct to reject this -- though the diagnostic could be better, especially when there's a space before the ::.

this code compiles:

class CLangTester {
 public:
    int test();
};

int ::CLangTester::test() {
    return {};
}

https://godbolt.org/z/TK57dYYT9

[zygoloid]

Yes. int is a keyword, not a "name, template-id, or computed-type-specifier". But an identifier such as uint16_t followed by a :: is always treated as forming a qualified access into uint16_t.

[shafik]

This cwg1828

[lichenxuan87]

The relevant rule is [basic.loolup.qual.general]/1:

If a name, template-id, or computed-type-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.

So clang is correct to reject this -- though the diagnostic could be better, especially when there's a space before the ::.

this code compiles:

class CLangTester {
public:
int test();
};

int ::CLangTester::test() {
return {};
}
https://godbolt.org/z/TK57dYYT9

There's a space between "uint16_t" and "::". I don't think the rule applies, as space is a common semantic separator.

[safocl]

The relevant rule is [basic.loolup.qual.general]/1:

If a name, template-id, or computed-type-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.

So clang is correct to reject this -- though the diagnostic could be better, especially when there's a space before the ::.

[basic.def]/1

Name lookup associates the use of a name with a set of declarations ([basic.def]) of that name.

This means that the rules of "name lookup" do not apply in this case (for definitions).

upd. The example with class access rules confirms this.

The access rules ([class.access]) are considered only once name lookup and function overload resolution ...