[
https://issues.apache.org/jira/browse/GROOVY-12481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18138187#comment-18138187
]
ASF GitHub Bot commented on GROOVY-12481:
-----------------------------------------
paulk-asert commented on PR #3015:
URL: https://github.com/apache/groovy/pull/3015#issuecomment-6640587300
Thanks for the review, Daniel. Taking your points in order:
1. INFERRED_TYPE dependency. typeReference only matters when this is
inferred as Class<T>, which happens only in a static context. In an instance
context it returns null, and the old path is the right one there. I checked
both contexts in dynamic, @TypeChecked and @CompileStatic modes:
- Static method, static {} initializer and closure: this::foo gives 42 in
all three modes.
- Instance context: this::foo, this::inst and this::toString give the
same results as before.
The writer doesn't read INFERRED_TYPE; it gets Class<T> from the type
chooser, so both halves agree.
2. Nested classes. testThisMethodReferenceInStaticContextOfNestedClass
covers this: this::foo inside Outer.Nested resolves to Nested::foo.
3. Native method references. this::foo compiles to the same invokedynamic
LambdaMetafactory call as C::foo; javap shows the two methods share the same
call-site entry. The native path needs no change.
4. Error wording. The message is "Failed to find class method 'inst()' for
the type: C", and the test asserts that text. It names the class, so it reads
the same as C::inst used as a Supplier.
One correction on framing: this isn't really Java alignment. Java rejects
this in a static context entirely. The goal is to make @CompileStatic agree
with dynamic Groovy and @TypeChecked, which already accept these forms.
The change also fixes two things beyond the original report:
- Compiler crash: under @TypeChecked and @CompileStatic, an instance method
referenced through this and used as a Function<C,…> crashed with "General error
during canonicalization: Index -1 out of bounds". It now compiles and works.
- Shadowed Class methods: if a class declares a static method matching a
java.lang.Class method, such as a static getName(), @CompileStatic used to pick
Class.getName() and return "C". It now calls the class's own method. That
matches dynamic Groovy, @TypeChecked, and this.getName() under @CompileStatic.
It's the only case where code that compiled before gives a different result,
and I'll mention it in the JIRA.
Also, this::new in a static context now compiles under @CompileStatic.
Dynamic Groovy and @TypeChecked already accepted it.
> SC: `this::method` in a static context fails to compile with "Failed to find
> method ... for the type: java.lang.Class<A>"
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-12481
> URL: https://issues.apache.org/jira/browse/GROOVY-12481
> Project: Groovy
> Issue Type: Improvement
> Components: Static compilation
> Affects Versions: 5.1.2, 6.0.0
> Reporter: Paul King
> Priority: Major
>
> h2. Description:
> In a static context, `this` is the class itself (a `Class<A>` value). Under
> {{@CompileStatic}}, a method reference with a {{this}} receiver in a static
> method, static initializer or static script method looks for the method on
> {{java.lang.Class}} only, not as a static method of the class. So
> {{this::foo}} fails to compile, although {{A::foo}}, {{this.foo()}} and
> {{this.&foo}} all work. With {{@TypeChecked}} or dynamic compilation,
> {{this::foo}} works.
> {code:groovy}
> import groovy.transform.CompileStatic
> import java.util.function.Supplier
> @CompileStatic
> class A {
> static foo() { 42 }
> static m() {
> Supplier s = this::foo
> s.get()
> }
> }
> assert A.m() == 42
> {code}
> {noformat}
> Failed to find method 'foo()' for the type: java.lang.Class<A>
> {noformat}
> ||Form, in a static method||{{@CompileStatic}}||{{@TypeChecked}}||dynamic||
> |{{this::foo}} (static {{foo()}})|*compile error*|42|42|
> |{{this::bar}} (static {{bar(int)}}, {{Function<Integer,Object>}})|*compile
> error*|works|works|
> |{{this::foo}} in a {{static \{ \}}} initializer|*compile error*|works|works|
> |{{this::foo}} in a static method of a script|*compile error*|works|works|
> |{{this::getSimpleName}} (method of {{java.lang.Class}})|"A"|"A"|"A"|
> |{{A::foo}}|42|42|42|
> |{{this.foo()}}|42|42|42|
> |{{this.&foo}}|42|42|42|
> |{{this::inst}} (instance method {{inst()}})|compile error (same wrong
> message)|{{MissingMethodException}} at runtime|{{MissingMethodException}} at
> runtime|
> Expected: in a static context, {{this::name}} resolves the way
> {{this.name()}} already does under {{@CompileStatic}}: first as a static
> method of the enclosing class, otherwise as a method of {{java.lang.Class}},
> so that {{this::getSimpleName}} keeps working. When neither exists, the error
> should name the enclosing class, not only {{Class<A>}}.
> Cause:
> {{StaticTypesMethodReferenceExpressionWriter.resolveMethodReferenceTarget}}
> treats only a {{ClassExpression}} receiver as a type reference. For any other
> receiver it takes the type from the type chooser, which for {{this}} in a
> static context is {{Class<A>}}. So the lookup runs against
> {{java.lang.Class}} and fails in {{validate}}. Because the error is raised
> during class generation, the type checker has already accepted the code,
> which is why {{@TypeChecked}} compiles it.
> Workaround: use {{A::foo}} or {{this.&foo}}.
> Note: Java rejects this in a static context entirely (and rejects
> this::staticMethod even in an instance context), so there's no Java behaviour
> to match. Groovy accepts both forms dynamically and with @TypeChecked, and
> @CompileStatic accepts the instance-context form, so the static-context case
> is the odd one out.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
