[
https://issues.apache.org/jira/browse/GROOVY-12488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18134634#comment-18134634
]
ASF GitHub Bot commented on GROOVY-12488:
-----------------------------------------
codeconsole commented on PR #3022:
URL: https://github.com/apache/groovy/pull/3022#issuecomment-6513953775
@paulk-asert @daniellansun I've split this as Paul suggested. This PR is now
group A, rebuilt on current master, so the conflicts are gone:
- A (here): d5395be, 9f9124f, 8fba262, f60c6e4, f35e725, 4169695, a358ba1,
f85f7e2, 50a8e6e, 51893ae, the constructor slices of 0b89f6c and 932d9e6, and
only `testFunctionCN25` from c854974. The run-time-package rule here covers
constructors: the `GroovyClassLoader` marker,
`AsmClassGenerator.isInSameRuntimePackage` and
`StaticInvocationWriter.isDirectlyAccessible`, which constructor references
use. There is a new test that a constructor reference compiled to class files
calls a protected or package-private constructor of the same package directly.
- Docs: a Groovy 7 entry in COMPATIBILITY.md for the overload, varargs,
null-to-primitive, visible-constructor and meta-class changes; a paragraph in
the method reference section of core-operators on how the constructor is
selected, which cases stay at run time, and that those need reflection metadata
in a native image; and the `GroovyClassLoader` javadoc now says that a subclass
whose collector defines classes itself takes the meta-class path where direct
access would work.
- B, the same rule for `new`, methods, fields, method references, `super$`
and the diagnostics (19f8427, c4b5728, 41c24c6, 1865f19, 3bf8589, the rest of
0b89f6c and 932d9e6, a4ef7fb, fe92a5f, 8c338c3, 94895f3): GROOVY-12568, #3097.
It builds on this PR. Its COMPATIBILITY entry covers the new compile errors for
`new` of a protected constructor of another package and for a protected method
through a superclass receiver, and `StaticInvocationWriter` now notes that the
constructor error is raised during class generation, so `@TypeChecked` stays
silent.
- C, each with its own issue and PR:
- package-private classes of another class loader (0e55d32): GROOVY-12569,
#3098, on top of B;
- `super.m()` of a package-private method across class loaders (b4b1b63):
GROOVY-12570, #3099, on top of B;
- `BroadcastChannel` subscriber after close (a270edd): GROOVY-12571, #3105;
- sleep-to-await test changes (bce20df, 99ad290): GROOVY-12572, #3100;
- `LogTest` (35346fd): GROOVY-12573, #3101. #3078 didn't include it.
This branch passes the `groovy`, `gls`, `bugs`, classgen and transform
packages (13,420 tests); only `bugs.Groovy12363` fails, as it does on master,
and #3096 fixes that.
> SC: constructor reference calls the constructor through the meta-class
> instead of directly
> ------------------------------------------------------------------------------------------
>
> Key: GROOVY-12488
> URL: https://issues.apache.org/jira/browse/GROOVY-12488
> Project: Groovy
> Issue Type: Improvement
> Components: Static compilation
> Affects Versions: 6.0.0
> Reporter: Scott Murphy Heiberg
> Priority: Major
>
> Under {{@CompileStatic}}, a constructor reference such as {{Made::new}} is
> implemented by a synthetic method {{ctorRef$<method>$<n>}} on the enclosing
> class, which the LambdaMetafactory call site targets. That method is not
> statically compiled:
> {noformat}
> private static final Made ctorRef$ctorRef$0();
> 0: ldc class Made
> 2: invokedynamic init:(Ljava/lang/Class;)Ljava/lang/Object;
> 7: invokedynamic cast:(Ljava/lang/Object;)LMade;
> 12: areturn
> {noformat}
> So every call selects the constructor through the meta-class at run time,
> while other method references ({{String::length}}, {{Math::abs}}) link their
> target directly. In a GraalVM native image the constructor also needs
> reflection metadata although the code is statically compiled.
> The cause is
> {{StaticTypesMethodReferenceExpressionWriter.addSyntheticMethodForConstructorReference}}:
> it builds the constructor call without a target constructor and sets
> {{STATIC_COMPILE_NODE}} to false (there is a TODO for it).
> Proposed fix: select the constructor at compile time among the constructors
> visible from the enclosing class, matched against the functional interface's
> parameter types as for a constructor call expression, and call it directly.
> Keep the run-time selection when no single constructor matches
> (GROOVY-10971), for a protected constructor in another package, and for a
> protected or package-private constructor of a class compiled in another
> compilation unit, which may come from another class loader. As with other
> method references and with Java, the constructor is then chosen from the
> declared parameter types rather than the run-time argument types.
> PR: https://github.com/apache/groovy/pull/3022
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
