[
https://issues.apache.org/jira/browse/GROOVY-12290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-12290:
-------------------------------
Description:
Accessing a private field of another class via property syntax compiles under
{{@TypeChecked}} (and runs, thanks to dynamic dispatch's historical leniency
about {{private}}) but fails to compile under {{@CompileStatic}}:
{code:groovy}
class P { private static final Map M = [a: 1] }
class C {
@groovy.transform.TypeChecked
def tc() { P.M } // compiles, runs
@groovy.transform.CompileStatic
def cs() { P.M } // "Access to P#M is forbidden"
}
{code}
The equivalent *method* case is already consistent: STC's method selection
filters candidates by visibility, so a private static method of another class
is rejected with the same {{[Static type checking]}} error in both modes.
Field/property resolution performed no such check — the receiver-type leniency
(GROOVY-7300, GROOVY-11358, which models dynamic Groovy's permissive private
access) admitted the field, and the access was only refused later, at bytecode
generation, by {{StaticTypesCallSiteWriter}} ({{"Access to X#Y is forbidden"}})
when it must emit a direct field access and no private-access bridge exists.
Compilation modes should not disagree: whatever passes type checking should
statically compile (same principle as GROOVY-12289).
*Fix:* the receiver-type leniency (extracted to
{{StaticTypeCheckingVisitor#isFieldAccessible}}) no longer admits plain
property syntax to a private field of a foreign nest, so both modes report the
standard {{No such property}} error at type-checking time (see also
GROOVY-7165, whose expected error moves from the late writer message to the STC
one). The deliberate dynamic escape hatches — which work at runtime in *all
three* modes today — are preserved:
* attribute access ({{new P().@f}}), Groovy's explicit encapsulation-piercing
operator
* closure bodies (GROOVY-9195), including delegate-resolved access ({{new
P().with \{ f \}}} and DSL/builder patterns generally) — closure property
dispatch stays dynamic-capable under static compilation
* nest-mate access via private bridges: closures reading the owner's private
fields, inner classes reading outer private statics, trait-private fields
* property syntax that resolves to an accessible accessor over a private field
Related adjustments:
* An inaccessible field no longer suppresses the read-only-property detection
(GROOVY-9127), so a class with a public getter, an out-of-scope setter and a
private field now reports {{Cannot set read-only property}} — identically in
both modes. This supersedes the GROOVY-11956 expectation that the map-style
constructor case compiles under {{@TypeChecked}} and fails only under
{{@CompileStatic}} (late, in the writer): it now fails consistently, arguably
completing that ticket's read-only story.
* Record component accessors ({{x()}} on precompiled records) now resolve in
STC's getter lookup, relocating the GROOVY-12225 writer-side fix: {{p.x}} types
via the accessor instead of leaning on the removed field leniency.
*Not changed:* the GROOVY-9195 closure exemption preserves a pre-existing
asymmetry — foreign-private field access is rejected in method bodies but
permitted in closure bodies (where it compiles to dynamic dispatch and works).
Unifying that would be a further behavior change with real DSL fallout, so it
is documented rather than removed.
*Migration note:* code that today compiles and runs under {{@TypeChecked}} only
(e.g. tests or frameworks reading another class's internals via property syntax
from a method body) becomes a compile error. Workarounds are straightforward
({{@PackageScope}}, an accessor, explicit {{.@}}, or a type-checking extension
— the error goes through the unresolved-property path, so
{{handleUnresolvedProperty}}/{{makeDynamic}} work as escape hatches). This
tightening should be called out in release notes and targeted at Groovy 6.
Dynamic Groovy is unaffected.
was:
Accessing a private field of another class via property syntax compiles under
{{@TypeChecked}} (and runs, thanks to dynamic dispatch's historical leniency
about {{private}}) but fails to compile under {{@CompileStatic}}:
{code:groovy}
class P { private static final Map M = [a: 1] }
class C {
@groovy.transform.TypeChecked
def tc() { P.M } // compiles, runs
@groovy.transform.CompileStatic
def cs() { P.M } // "Access to P#M is forbidden"
}
{code}
The equivalent *method* case is already consistent: STC's method selection
filters candidates by visibility, so a private static method of another class
is rejected with the same {{[Static type checking]}} error in both modes.
Field/property resolution performs no such visibility check; the access is only
refused later, at bytecode generation, by {{StaticTypesCallSiteWriter}}
({{"Access to X#Y is forbidden"}}) when it must emit a direct field access and
no private-access bridge exists. Compilation modes should not disagree:
whatever passes type checking should statically compile (same principle as
GROOVY-12289).
*Proposed fix:* enforce field/property visibility in
{{StaticTypeCheckingVisitor}}, mirroring the existing method-selection
visibility rules, so both modes report the error at the same place — rather
than making {{@CompileStatic}} accept an access it cannot compile without a
bridge.
*The check must be scoped narrowly.* The following all work today in *all
three* modes (dynamic, {{@TypeChecked}}, {{@CompileStatic}}) and must remain
untouched:
* attribute access ({{new P().@f}}) — Groovy's explicit encapsulation-piercing
operator; the static writer already compiles it via an access path that succeeds
* delegate-resolved access in closures ({{new P().with \{ f \}}} and
DSL/builder patterns generally)
* nest-mate style access covered by private bridges: closures reading the
owner's private fields, inner classes reading outer private statics, trait
methods reading trait-private fields
* property syntax that resolves to an accessible accessor over a private field
({{p.name}} with a public {{getName()}})
So the error should fire only for a *property expression* that resolves to a
*raw private field* of a class *outside the nest*, with *no accessible
accessor*, on a *non-delegate receiver*. The method-visibility machinery (and
the private-bridge metadata, {{PV_FIELDS_ACCESS}}) already encodes most of
these exemptions.
*Migration note:* code that today compiles and runs under {{@TypeChecked}} only
(e.g. tests or frameworks reading another class's internals via property
syntax) will become a compile error. Workarounds are straightforward
({{@PackageScope}}, an accessor, or explicit {{.@}}), but this tightening
should be called out in release notes and targeted at Groovy 6.
Dynamic Groovy is unaffected.
> Private field access from another class compiles under @TypeChecked but fails
> under @CompileStatic
> --------------------------------------------------------------------------------------------------
>
> Key: GROOVY-12290
> URL: https://issues.apache.org/jira/browse/GROOVY-12290
> Project: Groovy
> Issue Type: Bug
> Reporter: Paul King
> Priority: Major
>
> Accessing a private field of another class via property syntax compiles under
> {{@TypeChecked}} (and runs, thanks to dynamic dispatch's historical leniency
> about {{private}}) but fails to compile under {{@CompileStatic}}:
> {code:groovy}
> class P { private static final Map M = [a: 1] }
> class C {
> @groovy.transform.TypeChecked
> def tc() { P.M } // compiles, runs
> @groovy.transform.CompileStatic
> def cs() { P.M } // "Access to P#M is forbidden"
> }
> {code}
> The equivalent *method* case is already consistent: STC's method selection
> filters candidates by visibility, so a private static method of another class
> is rejected with the same {{[Static type checking]}} error in both modes.
> Field/property resolution performed no such check — the receiver-type
> leniency (GROOVY-7300, GROOVY-11358, which models dynamic Groovy's permissive
> private access) admitted the field, and the access was only refused later, at
> bytecode generation, by {{StaticTypesCallSiteWriter}} ({{"Access to X#Y is
> forbidden"}}) when it must emit a direct field access and no private-access
> bridge exists. Compilation modes should not disagree: whatever passes type
> checking should statically compile (same principle as GROOVY-12289).
> *Fix:* the receiver-type leniency (extracted to
> {{StaticTypeCheckingVisitor#isFieldAccessible}}) no longer admits plain
> property syntax to a private field of a foreign nest, so both modes report
> the standard {{No such property}} error at type-checking time (see also
> GROOVY-7165, whose expected error moves from the late writer message to the
> STC one). The deliberate dynamic escape hatches — which work at runtime in
> *all three* modes today — are preserved:
> * attribute access ({{new P().@f}}), Groovy's explicit encapsulation-piercing
> operator
> * closure bodies (GROOVY-9195), including delegate-resolved access ({{new
> P().with \{ f \}}} and DSL/builder patterns generally) — closure property
> dispatch stays dynamic-capable under static compilation
> * nest-mate access via private bridges: closures reading the owner's private
> fields, inner classes reading outer private statics, trait-private fields
> * property syntax that resolves to an accessible accessor over a private field
> Related adjustments:
> * An inaccessible field no longer suppresses the read-only-property detection
> (GROOVY-9127), so a class with a public getter, an out-of-scope setter and a
> private field now reports {{Cannot set read-only property}} — identically in
> both modes. This supersedes the GROOVY-11956 expectation that the map-style
> constructor case compiles under {{@TypeChecked}} and fails only under
> {{@CompileStatic}} (late, in the writer): it now fails consistently, arguably
> completing that ticket's read-only story.
> * Record component accessors ({{x()}} on precompiled records) now resolve in
> STC's getter lookup, relocating the GROOVY-12225 writer-side fix: {{p.x}}
> types via the accessor instead of leaning on the removed field leniency.
> *Not changed:* the GROOVY-9195 closure exemption preserves a pre-existing
> asymmetry — foreign-private field access is rejected in method bodies but
> permitted in closure bodies (where it compiles to dynamic dispatch and
> works). Unifying that would be a further behavior change with real DSL
> fallout, so it is documented rather than removed.
> *Migration note:* code that today compiles and runs under {{@TypeChecked}}
> only (e.g. tests or frameworks reading another class's internals via property
> syntax from a method body) becomes a compile error. Workarounds are
> straightforward ({{@PackageScope}}, an accessor, explicit {{.@}}, or a
> type-checking extension — the error goes through the unresolved-property
> path, so {{handleUnresolvedProperty}}/{{makeDynamic}} work as escape
> hatches). This tightening should be called out in release notes and targeted
> at Groovy 6.
> Dynamic Groovy is unaffected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
