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: Ian Lance Taylor <ian at airs dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: 09 Sep 2005 00:10:36 -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>
[ Redirected from gcc-patches@ to gcc@ ]
Mark Mitchell <mark@codesourcery.com> writes:
> This case is particularly tricky because of the fact that accepting
> the invalid code also means that we'll change the meaning of some
> valid code. For example, in:
>
> int f(int) {
> return 1;
> }
>
> struct S {
> friend int f(char) { return 2; }
> };
>
> int main () {
> return f('a');
> }
>
> we current return 2 from "main", which is incorrect. (Does your patch
> fix this, by the way? I'm not sure if we ever had the situation of an
> overload set in which some, but not all, functions were
> DECL_ANTICIPATED.)
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.
Ian