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 11:27:15 -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> <4321ACFA.70605@codesourcery.com>
Mark Mitchell <mark@codesourcery.com> writes:
> 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.
Thanks for the analysis.
Naturally, addressing that issue caused another problem, namely
g++.old-deja/g++.jason/scoping15.C. Because the call to imag in that
test case is written ::imag, the parser does not do argument dependent
lookup to find the function. So the compiler looks for a top-level
declaration for ::imag, and doesn't find one.
So, if we only do argument dependent lookup for unqualified names, and
we only find otherwise-undeclared friend functions using argument
dependent lookup, then is scoping15.C correct C++ or not?
Thanks for any insight on this one.
Ian