Yes, I can reproduce the error with your test case. I think what Jochen says is that this test does not correspond to the error you initially reported which is related to the ClassCodeVisitorSupport. There are two things mixed up here (well, I could identify more) : the regression which was introduced somewhere in ClassCodeVisitorSupport or any other class, and the bug which reproduces the StackOverflowError here, but which is not a regression as it could be identified in every version of Groovy tested so far.
Here's the result of my late investigations :
- the initial patch works if the superclass is public and a method is package private and the child class is defined in its own file (bug #1, fixed)
- if you remove the "public" modifier from the superclass definition, it fails with "class groovy.bugs.Groovy4922BugChild cannot access its superclass groovy.bugs.Groovy4922BugSupport" (bug #2, not fixed)
- if you remove the "protected" modifier on the "value" property of the superclass, it fails with "groovy.lang.MissingPropertyException: No such property: support for class: groovy.bugs.Groovy4922BugChild" (bug #3, not fixed but less critical)
- if you define the child class directly in the test case, like you did Hamlet, instead of in the "assertScript" section, it fails with a StackOverflowError (bug #4)
So, I would say your initial error is bug #5, which could be a modifier changed somewhere in the ClassCodeVisitorSupport class or its hierarchy between 1.7 and 1.8.
There's still some work to fully understand what's going on there