Re: [PATCH] Clean-up C's builtin function type matching.

[Jason Merrill <jason at redhat dot com>]

On 21 Jul 2003 19:42:42 +0200, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:

> Jason Merrill <jason@redhat.com> writes:
>
> | On 21 Jul 2003 16:56:40 +0200, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> | 
> | > | No, its not attribute related.  When the C++ builtins are initialized
> | > | they are marked as DECL_ANTICIPATED, with one anticipated decl being
> | > | placed in the global namespace and the other in the std:: namespace.
> | >
> | > Aha, now I get it.  I was arguing at the time, that we should have
> | > only one built-in tree (preferably in std::) and do a corresponding
> | > anticipated using-declaration at the global scope.  That way, we don't
> | > run into the possibility of ambiguity.  In fact, that is the way we
> | > want the built-ins to behave.
> | 
> | I don't think it matters whether we have two anticipated function decls or
> | one and an anticipated using-decl, so long as they do the right thing.
> | It's probably simpler not to introduce the concept of an anticipated
> | using-decl.
>
> Currently, we have two different function decls -- where they actually
> have to correspond to the same entity.

Yes.  The same sort of thing can occur in user code with extern "C"
declarations.

> Updating the attributes on on decl does not automatically reflect on the
> other -- which is wrong.

I disagree; I think that's as it should be.  Unless the user actually
writes a using-declaration, there's no reason for one declaration to affect
the other.

> If we were using a using-decl (a using-decl is an alias), then updating
> the attributes on one decl will reflect on the other.  We would not have
> a problem of getting ambiguity nor out-of-sync.
>
> | Either a using-decl should clobber an anticipated decl, or joust should
> | prefer real decls, or both.
>
> Given that a using-declaration in user code will always refer to an
> existing declaration, I would prefer we localize the anticipated
> declaration/built-in logic and not export it to joust. 

I was wrong to mention joust; the call resolution code already ignores
anticipated decls properly.  But resolve_address_of_overloaded_function
doesn't know to ignore anticipated decls, which it should regardless of the
presence of real decls.  Fixed thus:

*** class.c.~1~	2003-07-16 18:56:04.000000000 -0400
--- class.c	2003-07-21 14:53:49.000000000 -0400
*************** cannot resolve overloaded function `%D' 
*** 5769,5774 ****
--- 5769,5779 ----
  	    /* We're looking for a non-static member, and this isn't
  	       one, or vice versa.  */
  	    continue;
+ 
+ 	  if (DECL_ANTICIPATED (fn))
+ 	    /* Built-in functions that haven't been declared don't really
+ 	       exist.  */
+ 	    continue;
  	
  	  /* See if there's a match.  */
  	  fntype = TREE_TYPE (fn);