This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH RFC: Proposed patch for PR c++/7874
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Ian Lance Taylor <ian at airs dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 09 Sep 2005 08:40:42 -0700
- Subject: Re: PATCH RFC: Proposed patch for PR c++/7874
- References: <20050907054240.31559.qmail@gossamer.airs.com> <m3u0gx6olu.fsf@uniton.integrable-solutions.net> <m3ek80akcs.fsf@gossamer.airs.com> <005701c5b3cf$ab05e6a0$bf03030a@trilan> <m34q8waj3b.fsf@gossamer.airs.com> <431F26DD.6070009@codesourcery.com> <m3zmqm4syb.fsf@gossamer.airs.com>
Ian Lance Taylor wrote:
> Now that my patch handles the above case correctly, the test
> g++.dg/template/friend10.C fails. And the original test case in PR
> 5116 fails.
>
> I think the issue here is whether we should prefer an explicitly
> declared conversion operator over a friend function found using
> argument dependent lookup. With my current patch, we prefer the
> conversion operator. (When friends are injected, we prefer the friend
> function, which seems straightforward and correct.)
>
> Can somebody with more C++-fu than I have take a look at these two
> cases and see what is correct? Thanks.
Let's start with the simpler friend10.C. There, the "operator bool()"
conversion operator is irrelevant, as far as I can see. However, we
*should* still call the friend operator<<, because argument-dependent
lookup is explicitly defined that way.
So, in that particular form of lookup, you should ignore
DECL_ANTICIPATED -- but only if the friend was declared in one of the
classes that's in the set of special classes. I guess, without changing
our representation, you get to go through each of the DECL_ANTICIPATED
friends, and then call is_friend (fn, c) for each c in the set of
argument-dependent classes. That's wort-case quadratic, and we could
make it cleverer, but I'd start with that.
--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304