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 RFC: Proposed patch for PR c++/7874


Ian Lance Taylor wrote:

I understand what you are saying here.  The only reasonable fix I see
is to add a friend_p parameter to pushdecl, pushdecl_namespace_level,
pushdecl_with_scope, pushdecl_class_level, and maybe a couple of
others.  Then we unambiguously know that we are dealing with a friend
declaration, and can set DECL_ANTICIPATED reliably.  Then we need to
be able to distinguish an anticipated friend declaration from an
anticipated builtin declaration without relying on DECL_FRIEND_P.
Since it would seem to be possible (if strange) to declare a builtin
function as a friend, we can't use !DECL_BUILT_IN.  So I think we
might need a new bit in lang_decl_flags (unless we can overload an
existing one which is never set for a FUNCTION_DECL, although I don't
see one at first glance).

I will modify the patch along those lines if you think that would be
better.

I do think that would be better. I probably wouldn't require it before approving the patch; I'd probably just say that you should add a comment in duplicate_decls saying that in testing DECL_FRIEND_P on newdecl we're assuming that the new declaration was explicitly declared a friend, and that if that assumption is false, then we need to do as you say above. But, if you want to do it right, I'd sure like that better. I really do think DECL_FRIEND_P should go away; it's just a bug waiting to happen, and it's not a logical thing to have in an intermediate representation; there are no semantics associated.


This turned out to be fairly easy to fix by adding a condition in the
joust function to prefer officially declared functions over hidden
friend functions found via argument dependent lookup.

Makes sense. Cool. (Of course, with -finject-friends, you'll want to maintain the current behavior.)


--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304


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