From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24511 invoked by alias); 30 Mar 2006 21:06:08 -0000 Received: (qmail 24495 invoked by alias); 30 Mar 2006 21:06:04 -0000 Date: Thu, 30 Mar 2006 21:06:00 -0000 Message-ID: <20060330210604.24494.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c++/26950] Error diagnostic not issued for unacceptable result of lookup for a name used in a nested-name-specifier In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "widman at gimpel dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-03/txt/msg03011.txt.bz2 List-Id: ------- 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