[
https://issues.apache.org/jira/browse/GROOVY-10756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17602413#comment-17602413
]
Eric Milles edited comment on GROOVY-10756 at 9/9/22 4:44 PM:
--------------------------------------------------------------
This is a similar issue as described in GROOVY-10651. Binary and source types
get different treatment. Specifically the generics for "Collection<T>" are
different. When {{ResolveVisitor}} processes the source, it sets the type
{{File}} as the redirect for the {{T}} type parameter (see
{{ResolveVisitor#resolveGenericsType}}). However, both the ASM and ClassLoader
resolution (via {{ClassNodeResolver}}) leave "T -> Object" for the generics
type.
I may stil have some experimental code that walks the generics and fills this
info in. However, there are order of operations concerns that can lead to
stack overflow conditions in the decompiler code, which is one reason I never
got out of the experimental stage.
Update: The class file parsing is not too different in 3.0.10. The reason this
started failing in 3.0.11 is a change in
{{StaticTypeCheckingVisitor#inferReturnTypeGenerics}}.
was (Author: emilles):
This is a similar issue as described in GROOVY-10651. Binary and source types
get different treatment. Specifically the generics for "Collection<T>" are
different. When {{ResolveVisitor}} processes the source, it sets the type
{{File}} as the redirect for the {{T}} type parameter (see
{{ResolveVisitor#resolveGenericsType}}). However, both the ASM and ClassLoader
resolution (via {{ClassNodeResolver}}) leave "T -> Object" for the generics
type.
I may stil have some experimental code that walks the generics and fills this
info in. However, there are order of operations concerns that can lead to
stack overflow conditions in the decompiler code, which is one reason I never
got out of the experimental stage.
> STC: parameterized and bounded return value for java class property
> -------------------------------------------------------------------
>
> Key: GROOVY-10756
> URL: https://issues.apache.org/jira/browse/GROOVY-10756
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
> Affects Versions: 3.0.11, 4.0.4
> Reporter: J. Brébec
> Assignee: Eric Milles
> Priority: Major
>
> Given:
> * A Java class having a method returning a generic Collection,
> * A groovy script compiled with "CompileStatic" and using the method of the
> JavaClass
> Then the type of the element of the collection is not correctly inferred.
> Example:
> {code}
> public class Bridge { // java
>
> public <T extends File> Collection<T> getFiles() {
> return null;
> }
> }
> {code}
> and the following script:
> {code}
> @groovy.transform.CompileStatic
> def cst() {
> new Bridge().files.collect { it.name }
> }
> {code}
> the compilation fails with the error:
> {code}
> [Static type checking] - No such property: name for class: java.lang.Object
> {code}
> Note:
> - It works in v3.0.10 but not in v3.0.11
> - It works if the class is defined in the groovy script
> - A repro is available here: https://github.com/j3rem1e/groovy-bug-generic
> ({{>mvn test}})
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
