[Bug c++/26950] Error diagnostic not issued for unacceptable result of lookup for a name used in a nested-name-specifier

[Bug c++/26950] Error diagnostic not issued for unacceptable result of lookup for a name used in a nested-name-specifier

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.4.0
   Target Milestone|---                         |4.4.0

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This is rejected in C++11 mode (and later) since GCC 4.4.0

It was fixed somewhere between r139600 and r139623, almost certainly by r139611
(which added scoped enum support).

[Bug c++/26950] Error diagnostic not issued for unacceptable result of lookup for a name used in a nested-name-specifier

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
It's "fixed" for C++11 because N::a is meaningful for scoped enums, and fails
to find it. But the code is invalid even in C++03.

Clang and EDG both reject this even in C++03 mode. We might want to do the
same.

EDG with --c++03 says:

"e.C", line 3: error: name followed by "::" must be a class or namespace name
      enum N { e0 = N::a };
                    ^

"e.C", line 2: warning: variable "N::a" was declared but never referenced
      const int a = 42;
                ^

1 error detected in the compilation of "e.C".


Clang says:

e.C:3:19: warning: use of enumeration in a nested name specifier is a C++11
extension [-Wc++11-extensions]
    enum N { e0 = N::a };
                  ^
e.C:3:19: error: no member named 'a' in 'N::N'; did you mean simply 'a'?
    enum N { e0 = N::a };
                  ^~~~
                  a
e.C:2:15: note: 'a' declared here
    const int a = 42;
              ^
1 warning and 1 error generated.

[Bug c++/26950] Error diagnostic not issued for unacceptable result of lookup for a name used in a nested-name-specifier

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.0                       |---

[Bug c++/26950] Error diagnostic not issued for unacceptable result of lookup for a name used in a nested-name-specifier

[manu at gcc dot gnu dot org]

------- Comment #5 from manu at gcc dot gnu dot org  2008-02-10 14:08 -------
Confirmed in g++ 4.3.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu dot org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |accepts-invalid
      Known to fail|                            |4.3.0
   Last reconfirmed|0000-00-00 00:00:00         |2008-02-10 14:08:42
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26950

[Bug c++/26950] Error diagnostic not issued for unacceptable result of lookup for a name used in a nested-name-specifier

[widman at gimpel dot com]

------- Comment #4 from widman at gimpel dot com  2006-03-31 05:36 -------
Subject: Re:  Error diagnostic not issued for unacceptable result of lookup for
a name used in a nested-name-specifier


On Mar 30, 2006, at 11:47 PM, Daveed Vandevoorde wrote:

>
> On Mar 30, 2006, at 4:06 PM, James Widman wrote:
<snip>
>> "enum N" is not an enumerator name; it's an enumeration name (or  
>> an /enum-name/ [7.2p1]), so "enum N" cannot be ignored.
>
> Ah, you're right.  It turns out that the grammar in this area
> has changed since the 1998 standard (as John Spicer pointed
> out to me).  The 1998 version of the standard had
>
>   nested-name-specifier:
>           class-or-namespace-name :: nested-name-specifieropt
>           class-or-namespace-name :: template nested-name-specifier
>
> which meant only classes or namespace names were considered.
> That could be read as meaning that 3.4.3/1 never was reached
> with an enumeration type name, but there is no unanimity on
> that reading.
>
> With the current wording (which was introduced because the
> earlier wording didn't correctly deal with template-dependent
> qualifiers), it's pretty unambiguous that your example is
> ill-formed and we think the standard should not be changed
> in that regard.
>
> I've filed a defect numbered EDGcpfe/7621 to track this.
>
> Cheers,
>
> 	Daveed Vandevoorde
> 	Edison Design Group

Thanks; that should help to simplify our lookup routines ever-so- 
slightly. (:

For those with a superstitious bent, I'd like to point out that this  
week saw a total eclipse of the sun, news of genetically modified  
pigs (perhaps with wings next), and now it's been revealed that GCC  
and EDG have the same front end bug for a case where *every other C++  
front end* appears to get it right.

This is clearly a sign that the end is nigh.  It's apocalypse party  
time. (:


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26950

[Bug c++/26950] Error diagnostic not issued for unacceptable result of lookup for a name used in a nested-name-specifier

[widman at gimpel dot com]

------- Comment #3 from widman at gimpel dot com  2006-03-30 23:31 -------
Subject: Re:  Error diagnostic not issued for unacceptable result of lookup for
a name used in a nested-name-specifier


On Mar 30, 2006, at 4:06 PM, widman at gimpel dot com wrote:

> <snip>
> So when I read that excerpt of 3.4.3/1, I thought to myself:
>
> "During the lookup for a name preceding the :: scope resolution
> operator, ordinary names are ignored, except that typedef names and
> namespace names are considered."
>
> ... with the implication being that tag names (including the names of
> classes, unions, and enumerations) are considered without exception.

What was the intention in 3.4.3p1?  Presumably it's to prevent lookup  
from finding names that don't refer to namespaces or classes.  If  
that's the case then we probably want a change in wording here --  
maybe something like:

     During the lookup for a name preceding the ::
     scope resolution operator, only the following
     kinds of names are considered:

         - class-names,

         - class template names (when used to form
           a template-id),

         - namespace names, and

         - typedef names

     All other names are ignored.  If the name
     found does not designate:

         - a class,

         - a dependent type that could possibly
           refer to a class during instantiation,
           or

         - a namespace,

     then the program is ill-formed.  If the name
     designates a dependent type, no diagnostic is
     required.

(See also http://www.open-std.org/jtc1/sc22/wg21/docs/ 
cwg_active.html, item 215)

James Widman


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26950

[Bug c++/26950] Error diagnostic not issued for unacceptable result of lookup for a name used in a nested-name-specifier

[widman at gimpel dot com]

------- Comment #2 from widman at gimpel dot com  2006-03-30 21:06 -------
Subject:  Error diagnostic not issued for unacceptable result of lookup for a
name used in a nested-name-specifier



On Mar 30, 2006, at 2:56 PM, Daveed Vandevoorde wrote:

> Hi James,
>
> On Mar 30, 2006, at 2:31 PM, James Widman wrote:
>
>> [This can probably also be categorized as "low priority".]
>>
>> The GCC and EDG front ends both appear to think that this test  
>> case is well-formed:
>>
>> namespace N {
>>     const int a = 42;
>>     enum N { e0 = N::a };
>> }
>>
>> ... but I think 3.4.3p1 makes it ill-formed.
>
>
> Can you elaborate on that?  3.4.3/1 says:
>
> 	The name of a class or namespace member can be referred to
> 	after the :: scope resolution operator (5.1) applied to a
> 	nested-name-specifier that nominates its class or namespace.
> 	During the lookup for a name preceding the :: scope resolution
> 	operator, object, function, and enumerator names are ignored.
> 	If the name found is not a class-name (clause 9) or
> 	namespace-name (7.3.1), the program is ill-formed.
>
> So when looking up N in N::a, the "enum N" entry is ignored, and the
> "namespace N" entry is found.  "a" is a member of that namespace, and
> it can be used in an integral constant-expression.
>
> Am I missing something?
>
> 	Daveed Vandevoorde
> 	Edison Design Group


"enum N" is not an enumerator name; it's an enumeration name (or an / 
enum-name/ [7.2p1]), so "enum N" cannot be ignored.

In C (ignoring the namespace N for now), we would say that the  
enumeration name N resides in the tag name space (along with the tag  
names of structs and unions) and e0 resides in the ordinary name  
space (along with the names of functions, variables, and typedef  
names -- see C89: 3.1.2.3, C99:6.2.3).

So when I read that excerpt of 3.4.3/1, I thought to myself:

"During the lookup for a name preceding the :: scope resolution  
operator, ordinary names are ignored, except that typedef names and  
namespace names are considered."

... with the implication being that tag names (including the names of  
classes, unions, and enumerations) are considered without exception.

>> I also reported this to:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26950
>>
>> MSVC (6 through 8) and Borland 5.6 appear to treat the enum-name  
>> as hiding the namespace name during lookup for the nested-name- 
>> specifier.
>>
>> James Widman
>> -- 
>> Gimpel Software
>> http://gimpel.com
>>
>>
>


James Widman


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26950

[Bug c++/26950] Error diagnostic not issued for unacceptable result of lookup for a name used in a nested-name-specifier

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-03-30 20:02 -------
Hmm, Comeau C++ does not reject this code either (but that does not mean this
is not invalid code).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26950