--- 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
Sta
--- 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_us
--- 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_us
--- 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
--- 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
struct S : public T {
using X::f;
--- 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, fo
--- 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::B::foo;") are deprecated in current C++. The preferred way to w
--- 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 recomme
--- 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::B
during a call from cp_parser_constructor_declarator_p. That function sets
check_dependency_p to false, because we do have to resolve depe
--- 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::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
--- Comment #11 from nathan at gcc dot gnu dot org 2006-01-15 14:04 ---
What's happening is that we parse I::B as a type specifier and then squirrel
away a preparsed template type specifier, but because I::B is a
non-dependent type, the preparsed specifier becomes simply ::B, losing the
--- 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
12 matches
Mail list logo
