This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
[PATCH] followup on java/4715.
- From: Alexandre Petit-Bianco <apbianco at cygnus dot com>
- To: gcc-patches at gcc dot gnu dot org, java-patches at gcc dot gnu dot org
- Date: Fri, 29 Mar 2002 13:44:14 -0800 (PST)
- Subject: [PATCH] followup on java/4715.
- Reply-to: apbianco at redhat dot com
It turns out that Tom's patch to java/4715 is still required, as we're
now in the situation were unresolved types can be safely ignored. With
yesterday's fix, an endless loop situation could occur if certain type
couldn't be resolved at compile time (and previously reported as
such.)
I'm checking this in the trunk and the branch.
./A
2002-03-29 Tom Tromey <tromey@redhat.com>
* parse.y (check_inner_circular_reference): Ignore incomplete
types.
Index: parse.y
===================================================================
RCS file: /cvs/gcc/gcc/gcc/java/parse.y,v
retrieving revision 1.353.2.13
diff -u -p -r1.353.2.13 parse.y
--- parse.y 2002/03/28 07:42:50 1.353.2.13
+++ parse.y 2002/03/29 21:49:22
@@ -5245,14 +5245,23 @@ check_inner_circular_reference (source,
if (!basetype_vec)
return NULL_TREE;
-
+
for (i = 0; i < TREE_VEC_LENGTH (basetype_vec); i++)
{
- tree su = BINFO_TYPE (TREE_VEC_ELT (basetype_vec, i));
+ tree su;
+
+ /* We can end up with a NULL_TREE or an incomplete type here if
+ we encountered previous type resolution errors. It's safe to
+ simply ignore these cases. */
+ if (TREE_VEC_ELT (basetype_vec, i) == NULL_TREE)
+ continue;
+ su = BINFO_TYPE (TREE_VEC_ELT (basetype_vec, i));
+ if (INCOMPLETE_TYPE_P (su))
+ continue;
if (inherits_from_p (su, target))
return lookup_cl (TYPE_NAME (su));
-
+
for (ctx = DECL_CONTEXT (TYPE_NAME (su)); ctx; ctx = DECL_CONTEXT (ctx))
{
/* An enclosing context shouldn't be TARGET */