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: [C++ PATCH] Using declarations should not conflict (PR/2294) - TAKE 2


Jason Merrill <jason@redhat.com> wrote:

>> !   if (!DECL_ARTIFICIAL (decl))
>>       {
>>         if (old && TREE_CODE (old) != OVERLOAD)
>>    new_binding = ovl_cons (decl, ovl_cons (old, NULL_TREE));
>> *************** push_overloaded_decl (tree decl, int fla
>> *** 2004,2010 ****
>>    OVL_USED (new_binding) = 1;
>>       }
>>     else
>> -     /* NAME is not ambiguous.  */
>>       new_binding = decl;
>
> This could use a comment about why artificial decls are being handled
> specially.

It's basically a FIXME. There are fallouts everywhere if I build OVERLOADs
for artificial decls, I think most of the code isn't simply read for it. I
can add a FIXME note to it of course, but I'm surely not able to track down
all those problems. The patch as it is, though, is still an improvement over
our current situation.

>>         tree class_size = size_in_bytes (true_type);
>>         static const char alloc_name[] = "_Jv_AllocObject";
>>         use_java_new = 1;
>> !       if (!get_global_value_if_present (get_identifier (alloc_name),
>> !      &alloc_decl))
>>    fatal_error ("call to Java constructor with `%s' undefined",
>>          alloc_name);
>> !       if (is_overloaded_fn (alloc_decl))
>> !       {
>> !  if (really_overloaded_fn (alloc_decl))
>> !    fatal_error ("`%s' should never be overloaded", alloc_name);
>> !  alloc_decl = OVL_FUNCTION (alloc_decl);
>> !       }

> You can use OVL_CURRENT rather than check is_overloaded_fn.

OK.

> Also, that should be
>
>   internal_error ("`%D' should never be overloaded", alloc_decl);
>
> We really don't want to use %s formatters if there's a better option
> available,

OK.

> and I don't think this is an error worth aborting over.  The
> other one either, actually.

I was wondering the same when I was looking at the code. I'll update it to
use internal_error and send an updated patch when testing is finished.

Thank you for your reviews!

Giovanni Bajo


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