[
https://issues.apache.org/jira/browse/GROOVY-9565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17721075#comment-17721075
]
Daniel Demus commented on GROOVY-9565:
--------------------------------------
Well obviously if you disable static compilation on the problematic method,
thus not running StaticTypeCheckingSupport#applyGenericsContext, it will not
get into the endless loop. On the other hand that is not a resolution. It's at
best a workaround.
The attached project is just a repro example, while the original problem was
adding global compilestatic threw stackoverflows one after the other.
Your suggestion does not work when you have to compile and modify 200 times.
Please handle the problem in the compiler. This affected all versions I tried
in 3.x and early 4.x.
The problem is that the recursive code doesn't maintain a list of types it has
already traversed and thus cannot stop when it runs into the an already seen
type.
> StackoverflowError when using an abstract class with generic parameters as
> the return value of a closure
> --------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-9565
> URL: https://issues.apache.org/jira/browse/GROOVY-9565
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
> Affects Versions: 2.5.11, 2.5.12, 2.5.13
> Reporter: Daniel Demus
> Assignee: Eric Milles
> Priority: Major
> Labels: StackOverflowError
> Fix For: 2.5.14
>
>
> If you try to compile the project at
> [https://github.com/demus-nine/groovy-class-generic-stackoverflowerror]
> groovyc crashes with a StackoverflowError. This happens in
> org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport#applyGenericsContext(java.util.Map<org.codehaus.groovy.ast.GenericsType.GenericsTypeName,org.codehaus.groovy.ast.GenericsType>,
> org.codehaus.groovy.ast.ClassNode) in this bit of recursive code:
> {code:java}
> if (bound.isArray()) {
> return applyGenericsContext(spec, bound.getComponentType()).makeArray();
> }
> {code}
> although I have seen it throw in other methods in the
> StaticTypeCheckingSupport class.
>
> The class that is being handled is an abstract class with a generic
> parameter, but in the code using the type there aren't enough hints to the
> compiler to resolve the generic constraint, possibly because it is
> self-referential.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
