jdaugherty opened a new pull request, #3079: URL: https://github.com/apache/groovy/pull/3079
With static compilation, the doCall method of a closure is declared with the closure's inferred return type. When that type was a parameterized reference to a class of the current compilation unit, its type arguments were dropped, while a reference to a class read from bytecode kept them. The same source therefore compiled to a closure class with a different signature depending on what else was compiled, which defeats compile avoidance in incremental builds. Only the class node itself, which carries the declared type parameters, is replaced by its plain reference. A parameterized reference goes through the same check for unresolved generics as any other type. The return type of a packed closure is normalised the same way. `ClosureReturnTypeSignatureTest` compiles a class once together with the class of its closures' return type and once against it compiled, and compares the `doCall` signatures. It fails without the fix. The full core test suite passes with it. - Jira: [GROOVY-12550](https://issues.apache.org/jira/browse/GROOVY-12550) - Reproducer, with `groovyc` and a Gradle incremental build: https://github.com/jdaugherty/groovy-closure-return-type-signature - Backport to `GROOVY_5_1_X`: https://github.com/jdaugherty/groovy/commit/b7a2216499c6230bba22de54c084bf4207fc95a2, on the branch [`closure-return-type-signature-5_1_X`](https://github.com/jdaugherty/groovy/tree/closure-return-type-signature-5_1_X). Packed closures do not exist on 5.1.x, so it changes `createClosureClass` only. The full 5.1.x core test suite passes with it. The problem reproduces on 4.0.33 and 5.1.3 too. Could this be backported to 5.x once it is merged? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
