[Bug c++/22136] [4.1 regression] Rejects old-style using declaration

[Bug c++/22136] [4.1 regression] Rejects old-style using declaration

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2005-10-12 00:17 -------
Any news on this one?


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2005-09-10 05:19:25         |2005-10-12 00:17:49
               date|                            |


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

[Bug c++/22136] [4.1 regression] Rejects old-style using declaration

[mmitchel at gcc dot gnu dot org]

------- Comment #4 from mmitchel at gcc dot gnu dot org  2005-10-31 03:50 -------
Leaving as P2; we should fix this.


-- 


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

[Bug c++/22136] [4.1 regression] Rejects old-style using declaration

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2005-11-11 03:36 -------
For some reason we get the record B and not just I<T>::B which would be
dependent.

Looking more into it.


-- 


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

[Bug c++/22136] [4.1 regression] Rejects old-style using declaration

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2005-11-11 04:30 -------
The difference between having the use and the no use case is that we get
a nondependent name for naming the struct B which is just wrong.
Hmm, I think I found related rejects valid for before 4.1.0:
struct B {
            void foo();
};

namespace a
{
struct B {
};
}

template <typename T> class I : public a::B {};
template<> class I<int> : public B {};
template <typename T> class D : private I<T> {
            I<T>::B::foo;
};

D<int> i;

--------
This is not a regression though.
The error we get:
t.cc: In instantiation of `D<int>':
t.cc:18:   instantiated from here
t.cc:14: error: type `a::B' is not a base type for type `D<int>'

Now to figure out why we are getting a::B instead of D<T>::B like we get in the
using case.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org


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

[Bug c++/22136] [4.1 regression] Rejects old-style using declaration

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2005-11-11 05:22 -------
parser->scope is wrong when we call make_id_declarator.


-- 


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

[Bug c++/22136] [4.1 regression] Rejects old-style using declaration

[pinskia at gcc dot gnu dot org]

------- Comment #8 from pinskia at gcc dot gnu dot org  2005-11-11 05:35 -------
For some reason we are calling cp_parser_pre_parsed_nested_name_specifier.


-- 


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

[Bug c++/22136] [4.1 regression] Rejects old-style using declaration

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2005-11-11 05:40 -------
(In reply to comment #8)
> For some reason we are calling cp_parser_pre_parsed_nested_name_specifier.

Actually that is fine.
Though we got the wrong answer already in there.


-- 


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

[Bug c++/22136] [4.1/4.2 regression] Rejects old-style using declaration

[pinskia at gcc dot gnu dot org]

------- Comment #10 from pinskia at gcc dot gnu dot org  2006-01-14 05:57 -------
I think this should get higher than a P2 as this is a rejects valid and I even
identified which patch caused the regression.  CCing Mark.  Also the regression
which that patch fixed was an accepts invalid and just being diagnostic too
late (after template instantiate).  Also I should note that it has been more
than 48 hours (the rule goes into effect once the person who caused is
notified) quote from http://gcc.gnu.org/develop.html:


Patch Reversion

If a patch is committed which introduces a regression on any target which the
Steering Committee considers to be important and if:

the problem is reported to the original poster;
48 hours pass without the original poster or any other party indicating that a
fix will be forthcoming in the very near future;
two people with write privileges to the affected area of the compiler determine
that the best course of action is to revert the patch;
then they may revert the patch.

(The list of important targets will be revised at the beginning of each release
cycle, if necessary, and is part of the release criteria.)

After the patch has been reverted, the poster may appeal the decision to the
Steering Committee.

Note that no distinction is made between patches which are themselves buggy and
patches that expose latent bugs elsewhere in the compiler.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mmitchel at gcc dot gnu dot
                   |                            |org


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

[Bug c++/22136] [4.1/4.2 regression] Rejects old-style using declaration

[nathan at gcc dot gnu dot org]

------- Comment #11 from nathan at gcc dot gnu dot org  2006-01-15 14:04 -------
What's happening is that we parse I<T>::B as a type specifier and then squirrel
away a preparsed template type specifier, but because I<T>::B is a
non-dependent type, the preparsed specifier becomes simply ::B, losing the base
path information.

I think the bug is that the preparsed template id is saved regardless of the
check_dependency, is_declaration and type_p flags.  I spent some time looking
at this and got confused.  I really must allocate some time to look again.


-- 


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

[Bug c++/22136] [4.1/4.2 regression] Rejects old-style using declaration

[mmitchel at gcc dot gnu dot org]

------- Comment #12 from mmitchel at gcc dot gnu dot org  2006-01-15 23:12 -------
I agree that this should be a P1.

Why do we think I<T>::B is a non-dependent type?  It should be considered
dependent, because we may have a specialization of I for which B is not a base
class.  There are some cases in the parser where we must resolve dependent
types; I wonder if we're incorrectly doing that in this case.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P1


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

[Bug c++/22136] [4.1/4.2 regression] Rejects old-style using declaration

[mmitchel at gcc dot gnu dot org]

------- 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

[Bug c++/22136] [4.1/4.2 regression] Rejects old-style using declaration

[mmitchel at gcc dot gnu dot org]

------- Comment #14 from mmitchel at gcc dot gnu dot org  2006-01-16 00:04 -------
Created an attachment (id=10650)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10650&action=view)
Patch that disallows nested-name-specifiers for constructors when in class
scope.


This patch is not recommended, but it does seem to work, modulo the fact that
it makes this code fail even with -fpermissive:

  struct S { S::S(); };


-- 


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

[Bug c++/22136] [4.1/4.2 regression] Rejects old-style using declaration

[bangerth at math dot tamu dot edu]

------- Comment #15 from bangerth at math dot tamu dot edu  2006-01-16 00:10 -------
Subject: Re:  [4.1/4.2 regression] Rejects old-style using
 declaration


> 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.

That is of course exactly what I did :-)

I don't particularly care about this bug, we've already fixed this in our
sources. I do not know, however, how many people use older versions of our
library with newer compilers.

Best
  Wolfgang

-------------------------------------------------------------------------
Wolfgang Bangerth                email:            bangerth@math.tamu.edu
                                 www: http://www.math.tamu.edu/~bangerth/


-- 


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

[Bug c++/22136] [4.1/4.2 regression] Rejects old-style using declaration

[mmitchel at gcc dot gnu dot org]

------- Comment #16 from mmitchel at gcc dot gnu dot org  2006-01-18 21:55 -------
I'm still wrestling with this PR.

As I suggested earlier, I turned off the caching of nested-name-specifiers
unless we're in the check_dependency_p case.  However, that causes
g++.dg/parse/operator2.C to fail, for essentially the opposite reason.

On:

template <typename T> B<T>::C::operator typename B<T>::Y::X() const { return
0;\
 }

we cache the check_dependency_p lookup for B<T>::C, which is "typename
B<T>::C".  As a result, we don't enter the scope of B<T>::C when looking up
names in the type-specifier following the operator.

I think that we could fix that in cp_paser_conversion_function_id (by using
resolve_typename_type), but I'm afraid that it's not really safe to cache
either version of the nested-name-specifier lookup, and then return it for the
other case of check_dependency_p.

Still thinking.


-- 


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

[Bug c++/22136] [4.1/4.2 regression] Rejects old-style using declaration

[mmitchel at gcc dot gnu dot org]

------- Comment #17 from mmitchel at gcc dot gnu dot org  2006-01-18 22:25 -------
In retrospect, I wonder if we should be complaining about a using-declaration
in a template in the first place.  

For example, is:

  struct X { void f(); };

  template <typename T>
  struct S : public T {
    using X::f;
  };

actually invalid? 

Both EDG and G++ complain about this (saying that X is not a base class of
S<T>), but should that matter at this stage?


-- 


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

[Bug c++/22136] [4.1/4.2 regression] Rejects old-style using declaration

[mmitchel at gcc dot gnu dot org]

------- Comment #18 from mmitchel at gcc dot gnu dot org  2006-01-19 21:27 -------
I've spoken with the folks at EDG, and we all agree that we should not be
checking that, in "using S::f", "S" is a base class of the current class if
we're in a template; the set of base classes of the template is not, in
general, known at that point.  Adjusting do_class_using_decl fixes that
problem.

However, that fix will likely reopen the problem that our class-scope using
declarations are really just ARM access declarations, and, therefore, don't
work as people expect in templates.  At some point, we're really going to need
to *fix* that problem; in the meanwhile, I guess I can look for another way to
hack around that.


-- 


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

[Bug c++/22136] [4.1/4.2 regression] Rejects old-style using declaration

[mmitchel at gcc dot gnu dot org]

------- Comment #19 from mmitchel at gcc dot gnu dot org  2006-01-20 03:07 -------
Subject: Bug 22136

Author: mmitchel
Date: Fri Jan 20 03:07:49 2006
New Revision: 110016

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110016
Log:
        PR c++/22136
        * name-lookup.c (do_class_using_decl): Don't try to look up base
        classes in templates with dependent base types.
        PR c++/22136
        * g++.dg/template/using10.C: New test.
        * g++.dg/temlpate/using11.C: Likewise.
        * g++.dg/inherit/using5.C: Tweak error messages.

Added:
    branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/using10.C
    branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/using11.C
Modified:
    branches/gcc-4_1-branch/gcc/cp/ChangeLog
    branches/gcc-4_1-branch/gcc/cp/name-lookup.c
    branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_1-branch/gcc/testsuite/g++.dg/inherit/using5.C


-- 


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

[Bug c++/22136] [4.1/4.2 regression] Rejects old-style using declaration

[mmitchel at gcc dot gnu dot org]

------- Comment #20 from mmitchel at gcc dot gnu dot org  2006-01-20 03:08 -------
Subject: Bug 22136

Author: mmitchel
Date: Fri Jan 20 03:07:58 2006
New Revision: 110017

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110017
Log:
        PR c++/22136
        * name-lookup.c (do_class_using_decl): Don't try to look up base
        classes in templates with dependent base types.
        PR c++/22136
        * g++.dg/template/using10.C: New test.
        * g++.dg/temlpate/using11.C: Likewise.
        * g++.dg/inherit/using5.C: Tweak error messages.

Added:
    trunk/gcc/testsuite/g++.dg/template/using10.C
    trunk/gcc/testsuite/g++.dg/template/using11.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/name-lookup.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/inherit/using5.C


-- 


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

[Bug c++/22136] [4.1/4.2 regression] Rejects old-style using declaration

[mmitchel at gcc dot gnu dot org]

------- Comment #21 from mmitchel at gcc dot gnu dot org  2006-01-20 03:36 -------
Fixed in 4.1.0.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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