From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-264646-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 28710 invoked by alias); 9 Jun 2010 08:44:44 -0000
Received: (qmail 28700 invoked by uid 22791); 9 Jun 2010 08:44:43 -0000
X-SWARE-Spam-Status: No, hits=-1.7 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM
X-Spam-Check-By: sourceware.org
Received: from mail-wy0-f175.google.com (HELO mail-wy0-f175.google.com) (74.125.82.175)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 Jun 2010 08:44:39 +0000
Received: by wyi11 with SMTP id 11so1337wyi.20        for <gcc-patches@gcc.gnu.org>; Wed, 09 Jun 2010 01:44:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.89.202 with SMTP id c52mr4650092wef.66.1276073076549; Wed, 	09 Jun 2010 01:44:36 -0700 (PDT)
Received: by 10.216.12.15 with HTTP; Wed, 9 Jun 2010 01:44:36 -0700 (PDT)
In-Reply-To: <AANLkTimaAXfekM-PgbSbSQqh5msFB6HCOqP_Hm8MBeuv@mail.gmail.com>
References: <AANLkTikY4pcci892bD0M2MsbakFvrK4r15csPFSLT5nO@mail.gmail.com>	<4C0EB10C.3050701@redhat.com>	<AANLkTimaAXfekM-PgbSbSQqh5msFB6HCOqP_Hm8MBeuv@mail.gmail.com>
Date: Wed, 09 Jun 2010 09:23:00 -0000
Message-ID: <AANLkTik7I3x2YgYpyLyKecAE2o3lxeKHmoLqy1PlSUQS@mail.gmail.com>
Subject: Re: [Patch] PR c++/26256
From: =?UTF-8?Q?Fabien_Ch=C3=AAne?= <fabien.chene@gmail.com>
To: Jason Merrill <jason@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-IsSubscribed: yes
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2010-06/txt/msg00869.txt.bz2

2010/6/9 Fabien Ch=C3=AAne <fabien.chene@gmail.com>:
> 2010/6/8 Jason Merrill <jason@redhat.com>:
>> Hunh, I thought I had reviewed this already. =C2=A0Sorry for the delay.
>
> Do not apologize, you already did :-) I was working slowly on what you
> have suggested.
>
>>> I've tried a naive approach: basically, when a field
>>> decl is ambiguous, lookup_member (invoked with protect =3D 1) returns a
>>> TREE_LIST. So when we are in this case, I have implemented a lookup in
>>> the object scope, which try to disambiguate the field decl using
>>> 'using decl'. If the lookup succeeds, just return the selected field
>>> decl in the TREE_LIST.
>>
>> It seems like this only works if there is a using in the most derived cl=
ass;
>> a using in an intermediate class wouldn't avoid the ambiguity.
>
> Yes, and I think the below code is illegal, don't you think so ?
>
> struct A { int next; };
> struct B { int next; };
> struct C : B { using B::next; };
>
> struct D : A, C
> {
> =C2=A0 =C2=A0// using C::next;
> =C2=A0 =C2=A0void f() { next =3D 1; }
> };

Ah, perhaps you mean that;

struct A { int next; };
struct B { int next; };
struct C : A, B { using B::next; };

struct D : C
{
    void f() { next =3D 1; }
};

I'll check.

--=20
Fabien