[Bug c++/62116] New: Allowing redeclaration of global variable x using ::x

[Bug c++/62116] New: Allowing redeclaration of global variable x using ::x

[yaghmour.shafik at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62116

            Bug ID: 62116
           Summary: Allowing redeclaration of global variable x using ::x
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: yaghmour.shafik at gmail dot com

Given the following code:

int x;

int main() {
    int(::x); //does not compile
    int(::x + 2); //compiles
}

gcc 4.9 will compile it without an error while gcc 4.8.x and clang 3.4 will
generate an error. For gcc 4.8.x the error is:

error: invalid use of qualified-name '::x'
     int(::x); //does not compile
            ^

and clang gives the following error:

error: definition or redeclaration of 'x' cannot name the global scope
    int(::x); //does not compile
        ~~^

as far as I can tell both gcc 4.8.x and clang are correct here based on my
reading of section 8.3 paragraph 6:

int(::x) ;

is equivalent to:

int ::x ;

which is not valid.

The problem originally cam up in the following Stackoverflow question:

http://stackoverflow.com/questions/24623071/is-typex-valid

[Bug c++/62116] Allowing redeclaration of global variable x using ::x

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62116

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Shafik Yaghmour from comment #0)
> as far as I can tell both gcc 4.8.x and clang are correct here based on my
> reading of section 8.3 paragraph 6:
> 
> int(::x) ;
> 
> is equivalent to:
> 
> int ::x ;
> 
> which is not valid.

Current G++ and EDG both treat it as the valid expression (int)::x

[Bug c++/62116] Allowing redeclaration of global variable x using ::x

[yaghmour.shafik at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62116

--- Comment #2 from Shafik Yaghmour <yaghmour.shafik at gmail dot com> ---
I am happy to be mistaken here, but it seems like section 6.8 paragraph 1
applies, for example if we have the following:

int(y) = 10;

it is being treated as a declaration not a cast and further more section 6.8
comments on an ill-formed example and says:

This is of course ill-formed for semantic reasons, but that does not affect the
syntactic analysis.

so even though:

int(::x);

would be ill-formed we are forced to treat it as a declaration and not a
function style cast.

[Bug c++/62116] Allowing redeclaration of global variable x using ::x

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62116

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-02-20
     Ever confirmed|0                           |1

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Confirmed then. Thanks, Richard.

[Bug c++/62116] Allowing redeclaration of global variable x using ::x

[rs2740 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62116

TC <rs2740 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rs2740 at gmail dot com

--- Comment #5 from TC <rs2740 at gmail dot com> ---
Somewhat related: http://stackoverflow.com/questions/28955859

struct Foo {
     enum { bar };
     explicit Foo(int){}
};

struct Baz { explicit Baz(Foo){} };

Baz b(Foo(Foo::bar)); // 1

Line #1 should be ill-formed because it fits the grammar for a function
declaration and is disambiguated as such. GCC considers it a variable
declaration instead. Clang rejects it - see
https://llvm.org/bugs/show_bug.cgi?id=4594.