------- Comment #13 from mmitchel at gcc dot gnu dot org 2006-01-15 23:57 ------- The problem is that we originally encounter the nested name specifier I<T>::B during a call from cp_parser_constructor_declarator_p. That function sets check_dependency_p to false, because we do have to resolve dependency names when parsing declarators. The result of the nested name specifier lookup is cached at that point, with the result that when we re-encounter it, we use the value we got before, even though that is no longer correct.
Because the caching should not be required for correctness (although it does eliminate duplicate error messages in some cases), we could probably disable the caching. Another approach would be not to look for the nested name specifier in class scope, since there it is not valid to declare a constructor in-class as "C::C", although we have long accepted that, with a warning. Preliminary testing shows that will fix the bug, although it will break struct S { S::S(); }; which is current accepted with -fpermissive. I will attach that patch for reference. Because of the problem with -fpermissive, I think it's better to try conditionalizing the caching in cp_parser_nested_name_specifier_opt on check_dependency. That also fixes the bug; I'm testing that patch now. For the original submitter: ARM-style access declarations (e.g., "I<T>::B::foo;") are deprecated in current C++. The preferred way to write the code is now "using I<T>::B::foo;", and that additional contextual information avoids the bug in G++ as well. So, the best immediate workaround is to insert the "using" keyword. -- mmitchel at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|nathan at gcc dot gnu dot |mark at codesourcery dot com |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22136