[
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 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 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
