Bug 11764 (cwg147)

Summary: [DR147] g++ does not treat injected class name correctly.
Product: gcc Reporter: Gabriel Dos Reis <gdr>
Component: c++Assignee: Jason Merrill <jason>
Status: RESOLVED FIXED    
Severity: normal CC: andrew.stubbs, angray, chrbr, christian.joensson, dodji, dushistov, egallager, fang, gcc-bugs, giovannibajo, gp.bolton, hans.ekkehard.plesser, ian, in10semotions, marc.glisse, msebor, pi3orama, pinskia, Woebbeking
Priority: P2 Keywords: accepts-invalid
Version: 3.3.1   
Target Milestone: 4.5.0   
See Also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102468
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33659
Host: Target: *-*-*
Build: Known to work:
Known to fail: Last reconfirmed: 2005-12-11 23:25:28

Description Gabriel Dos Reis 2003-08-01 17:00:36 UTC
cc1plus does not implement the class name injection correctly.
In particular the snipped below should be rejected on the basis that
A::A does not name a type (it designates a constructor)

  struct A { };

  int main()
  {
     A::A a;       // should be an ERROR
  }
Comment 1 Andrew Pinski 2003-08-01 18:39:00 UTC
I can confirm this in the mainline (20030730).
ICC 6.0 rejects this, so does EDG 2.40.
Comment 2 Gabriel Dos Reis 2003-08-01 18:43:01 UTC
Subject: Re:  g++ does not treat injected class name correctly.

"pinskia at physics dot uc dot edu" <gcc-bugzilla@gcc.gnu.org> writes:

| I can confirm this in the mainline (20030730).
| ICC 6.0 rejects this, so does EDG 2.40.

It should be noted that the last two compilers behave as required by
the standard. 

   http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#147

-- Gaby
Comment 3 Andrew Pinski 2004-08-04 17:29:15 UTC
*** Bug 16877 has been marked as a duplicate of this bug. ***
Comment 4 Giovanni Bajo 2004-08-04 23:32:16 UTC
A testcase is already in the tc1 testsuite (g++.dg/tc1/dr147.C), xfailed. I'm 
adding a cross-reference to this PR as we speak.
Comment 5 Andrew Pinski 2004-08-27 01:52:55 UTC
*** Bug 15865 has been marked as a duplicate of this bug. ***
Comment 6 Andrew Pinski 2004-08-27 01:54:27 UTC
*** Bug 11487 has been marked as a duplicate of this bug. ***
Comment 7 David Fang 2007-05-08 20:44:38 UTC
Still accepts-invalid as of 4.2-20070430 (RC2).
Comment 8 Wolfgang Bangerth 2007-10-04 18:46:46 UTC
*** Bug 33659 has been marked as a duplicate of this bug. ***
Comment 9 Andrew Pinski 2008-05-23 05:44:53 UTC
*** Bug 36306 has been marked as a duplicate of this bug. ***
Comment 10 Andrew Pinski 2008-06-11 23:44:41 UTC
*** Bug 36501 has been marked as a duplicate of this bug. ***
Comment 11 Andrew Pinski 2009-04-27 04:10:39 UTC
*** Bug 39924 has been marked as a duplicate of this bug. ***
Comment 12 Andrew Pinski 2009-05-29 15:15:03 UTC
*** Bug 40294 has been marked as a duplicate of this bug. ***
Comment 13 André Wöbbeking 2009-05-30 08:46:22 UTC
If you're sure that it's a bug why isn't it fixed yet? Is it that hard that you need more than six years?

Sure it's no show stopper but it's annoying. I'm using -pedantic and -ansi to ensure platform independent code and then this...
Comment 14 Ian Lance Taylor 2009-05-30 16:03:09 UTC
gcc is a free software project driven largely by volunteers.  Interest in fixing accepts-invalid bugs is generally low; people are generally more interested in rejects-valid bugs, or in better optimizations, or in avoiding regressions.  There are, unfortunately, many open bugs, many of which have higher priority than this one.  If this bug is important to you, you do have the option of fixing it yourself.
Comment 15 André Wöbbeking 2009-06-01 10:28:13 UTC
Ian, I know open source and I also know that some parts are more interesting than others :-) 


Most the time I'm a happy GCC user (sure, it could be faster but that's what compile farms are for). But this bug is assigned for nearly 6 years now that makes me a bit sad.
Comment 16 Andrew Pinski 2009-11-16 06:21:57 UTC
*** Bug 42064 has been marked as a duplicate of this bug. ***
Comment 17 Paolo Carlini 2009-11-16 14:06:25 UTC
Gaby, I'm sorry, are you actively working on this issue?
Comment 18 Jason Merrill 2009-11-23 22:57:04 UTC
Mine now.
Comment 19 Jason Merrill 2009-11-24 20:55:43 UTC
Subject: Bug 11764

Author: jason
Date: Tue Nov 24 20:55:24 2009
New Revision: 154519

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154519
Log:
	PR c++/42137
	* parser.c (cp_parser_mem_initializer_id): Pass typename_type to
	cp_parser_class_name.
	(cp_parser_unqualified_id): Same, rather than class_type.

	PR c++/11764
	* parser.c (cp_parser_expression_statement): Give helpful error
	for constructor name used as type.

Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/parser.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/lookup/name-clash4.C
    trunk/gcc/testsuite/g++.dg/tc1/dr147.C
    trunk/gcc/testsuite/g++.old-deja/g++.pt/ctor2.C

Comment 20 Jason Merrill 2009-11-24 21:05:12 UTC
Fixed.
Comment 21 Andrew Pinski 2010-04-09 02:56:57 UTC
*** Bug 43649 has been marked as a duplicate of this bug. ***
Comment 22 André Wöbbeking 2013-02-20 16:31:47 UTC
Hi,

shouldn't

struct A
{
    struct B {};
};

int main()
{
    A::A::B b;
}

fail to compile? It compiles with 4.6 and 4.7.


Cheers,
André
Comment 23 Jonathan Wakely 2013-02-20 17:03:00 UTC
No, that's valid. In the nested-name-specifier the second A only considers namespaces, types and templates whose specializations are types ([basic.lookup.qual]) so it doesn't name the constructor.
Comment 24 André Wöbbeking 2013-03-15 09:25:02 UTC
OK, I read some explanations in the duplicates but still don't know why this should be valid code. IMO it makes no sense to write A:A:A:B and given the facts that
1) people don't write this intentionally
2) people expect this to be invalid (see number of duplicates)
3) some other compiler don't compile this
couldn't you at least give us a warning (e. g. with -pedantic)?
Comment 25 Jason Merrill 2013-03-15 13:36:11 UTC
(In reply to comment #24)
> OK, I read some explanations in the duplicates but still don't know why this
> should be valid code.

That is a question for the standards committee.

> IMO it makes no sense to write A:A:A:B and given the facts that
> 1) people don't write this intentionally
> 2) people expect this to be invalid (see number of duplicates)

And the cases that are invalid were fixed by my patch.

> 3) some other compiler don't compile this

Which?  Recent versions of EDG and clang both accept the testcase in comment 22.

> couldn't you at least give us a warning (e. g. with -pedantic)?

-pedantic means "strictly enforce the standard"; since the standard says that the testcase in comment 22 is well-formed, -pedantic should not complain about it.  Someone could add another warning flag to warn about this, but it isn't a priority for me.
Comment 26 André Wöbbeking 2013-03-15 13:45:50 UTC
(In reply to comment #25)
> (In reply to comment #24)
> > 3) some other compiler don't compile this
> 
> Which?  Recent versions of EDG and clang both accept the testcase in comment
> 22.

MSVC 2010

In another duplicate ICC 6 was mentioned.

> > couldn't you at least give us a warning (e. g. with -pedantic)?
> 
> -pedantic means "strictly enforce the standard"; since the standard says that
> the testcase in comment 22 is well-formed, -pedantic should not complain about
> it.  Someone could add another warning flag to warn about this,

Yep, that is probably the better solution.
Comment 27 Jonathan Wakely 2013-03-15 13:49:58 UTC
(In reply to comment #26)
> > Which?  Recent versions of EDG and clang both accept the testcase in comment
> > 22.
> 
> MSVC 2010

"Other compilers have bugs" doesn't seem like a good reason to change GCC.
 
> In another duplicate ICC 6 was mentioned.

That's ancient, isn't it?