Eric Milles created GROOVY-11402:
------------------------------------
Summary: STC: inferred type of this.name within closure
Key: GROOVY-11402
URL: https://issues.apache.org/jira/browse/GROOVY-11402
Project: Groovy
Issue Type: Bug
Components: Static Type Checker
Affects Versions: 4.0.21, 3.0.21
Reporter: Eric Milles
Assignee: Eric Milles
Consider the following:
{code:groovy}
class C extends HashMap<String,String> {
private Object f = 'field'
private static Object g = 'field'
@groovy.transform.TypeChecked
void test() {
{->
def a = f
println a // entry
def b = g
println b // field
def c = this.f
println c // entry or field (if SC)
def d = this.g
println d // field
}()
}
}
new C().test()
{code}
GROOVY-11367, GROOVY-11401
Fixes in Groovy 3 [1] and 4 [2] have made it so that "g" and "this.g" resolve
to the static field (even from outer class). Groovy 5 has dropped this special
case and should go through the closure's {{getProperty}} protocol. This is at
least consistent with "g" and "this.g" appearing outside of a closure.
However, "f" and "this.f" have some inconsistencies. "f" resolves to entry for
STC and SC. "this.f" resolves to field at compile time for STC and SC. But to
entry for STC and field for SC at run time. Should "this.a" be entry within
closure as "a" is for all cases? Or should only the STC inferred type be fixed
to match the run time behavior -- leaving SC unchanged?
[1]
https://github.com/apache/groovy/commit/419ce2f91754f101d8e65977da4dc7e8e6b6265f
[2]
https://github.com/apache/groovy/commit/3c2266e053c4a9a9127be43921afb0c5135725f6
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
