This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] PR c++/26256


2010/6/8 Jason Merrill <jason@redhat.com>:
> Hunh, I thought I had reviewed this already. ÂSorry 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 = 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 class;
> 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
{
    // using C::next;
    void f() { next = 1; }
};

Nevertheless, I think that it is legal if 'using C::next' is
uncommented. I'll try this testcase.

> I'd prefer to tear out the old access declaration code and actually handle
> USING_DECLs directly in lookup_field_r et al.

That's what I'm trying to do, bootstrap is OK with all default
languages, and C only. Regtesting is in progress ...

-- 
Fabien


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]