[compiler] Broken code causes infinite loop

Looks like it happened during reconcile and not during save since restarting my eclipse and the class has no extends clause (and hence was never saved).

i'll take it as I'm in this code right now anyway.

Raised groovy bug http://jira.codehaus.org/browse/GROOVY-3904. Groovyc suffers from this problem - 1.7 even worse than 1.6.

I don't think you just hit it in reconciling, your extends clause vanished because saves don't seem to work so well sometimes if you have to kill eclipse shortly afterwards.

testcase committed into the groovy simple test set

Is there any difference at all in the 2 commented out tests - testRecursion_GR531() / testRecursion_GR531_2()?

GROOVY-3904 reported slightly different tests, but here I think both are exactly the same.

> Is there any difference at all in the 2 commented out tests - testRecursion_GR531() / testRecursion_GR531_2()?

yes, one has a main method and one does not - but I agree that may not make a difference to the failing scenario.

Although it seems fixed in groovy 1.7.0 - that change doesn't seem to be in groovy-eclipse, will look to pick it up next time I grab groovy (likely 1.7.2).

Still a problem for me.

not sure why we haven't picked up this fix when picking up the groovy versions...

Still a problem after the switch to 1.7.3.

The problem is happening in this method (maybe in other places too, but here is where I am experiencing it):

InnerClassVisitor.java

    private int getObjectDistance(ClassNode node) {
        int count = 1;
        while (node!=null && node!=ClassHelper.OBJECT_TYPE) {
            count++;
            node = node.getSuperClass();
        }
        return count;
    }

In this case, node.redirect() == node, so this loops forever. And this is fixed on the command line. Perhaps the reason that it works on the command line and not in Eclipse is that groovy on the command line will fail before getting to this point above, whereas Eclipse attempts to be recoverable.

Assigning to Andy. Perhaps an easy enough fix for the 2.0.2 release, but more likely it will have to wait.

Still a problem...easy enough fix for 2.1.0Release?

It seems that there are a lot of places in the code where the assumption is that the super class is not the calling class. I created a patch, but do not feel comfortable applying it since there are lots of little changes involved.

Also, this will still fail if there is a circular hierarchy, but the circularity is not direct. eg-

class A extends B { }
class B extends A { }

would have similar infinite loops. Even if this occurs just for a moment.

Patch on org.codehaus.groovy bundle

Will not get to for the 2.1.0 release.

let me review the patch and look to get this into the next version.

I looked at the patch and it touched a lot of places (basically wherever hierarchies are walked). More have been added since the patch was made too. I felt we needed a different approach to ensure we don't patch far too many new places.

The problem here is that although groovy have now fixed their issue we (in eclipse) attempt to get all the way through compilation, we don't give up on the first problem. IDEs typically try to show as much that is wrong about a file as possible, rather than you fix one thing, it shows the next, and so on.

So, I've added bitflags to ClassNode. When groovy determines an error we mark the ClassNode as having an inconsistent hierarchy. If someone later tries to access the superclass or superinterfaces for an inconsistent classnode (by calling one of the getter methods) we don't return the 'bad' supertype, we return Object for the superclass and an empty list for the interfaces.

This could be improved a little further because it considers all supertypes bad if just one is a problem. But at least it stops the hanging.

This approach also means we only have to patch ClassNode and the error logic that determines the ClassNode is broken, we don't have to patch anything else.

Changes and testcases added.