[C++ PATCH]: make cp_tree_equal unequivocal

[Mark Mitchell]

On Wed, 2003-06-18 at 03:38, Nathan Sidwell wrote:
> Mark Mitchell wrote:
> 
> > The comment at the top of cp_tree_equal should change, right?  (It no
> > longer is ever supposed to return -1.)
> yes. I then wandered into comptypes, and this patch supercedes the previous
> one. I suspect I can go through some callers of comptypes (duplicate_decls
> et al), to boolify them
> 
> The RELAXED checking for enumerations and java types does not appear
> to be used anywhere.
> 
> > Does your change make sense for comptypes, which seems to be the only
> > places checking for a negative return value?  It looks to me like for
> > UNBOUND_CLASS_TEMPLATE comptypes would have always returned 0; as far as
> > I can see cp_tree_equal always returns -1 for IDENTIFIER_NODES.  (I'm
> > not sure that cp_tree_equal should even be *called* with an
> > IDENTIFIER_NODE; it really should get expressions, but that's another
> > issue...)
> you get identifier nodes in SCOPE_REFs. Remember there is a test at the
> top checking for node equality.
> 
> booted & tested on i686-pc-linux-gnu, ok?

Wow, this is very exciting -- lots of cruft going away.

How did you get away with assuming comp_target_types never sees an
ARRAY_TYPE?  What about something like "int (*p)[5]"?

Also, I think this patch is a little too aggressive in cp_tree_equal:

!     case COMPONENT_REF:
!       if (TREE_OPERAND (t1, 1) != TREE_OPERAND (t2, 1))
!       return false;

I think we should continue to recur on that operand; I'm pretty sure we
have COMPONENT_REFs and/or SCOPE_REFs with TEMPLATE_ID_EXPRs as the
field, and better safe than sorry...

OK with an explanation for the question above and the change below.

Thanks; this cleanup will make some of that code a lot simpler...

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com