Within VariableExpressionTransformer, this one addition from your change stops the error. However, I don't know the implications of setting this metadata. In theory, a dynamic variable within a "with" closure is supposed to be satisfied from the delegate first. This change is forcing it to be satisfied from the owner.

    private static Expression tryTransformDelegateToProperty(VariableExpression expr) {
        ...

        ClassNode owner = expr.getNodeMetaData(StaticCompilationMetadataKeys.PROPERTY_OWNER);
        if (owner != null) {
            receiver.putNodeMetaData(StaticTypesMarker.INFERRED_TYPE, owner);
            receiver.putNodeMetaData(StaticTypesMarker.IMPLICIT_RECEIVER, val);
            // add
            receiver.putNodeMetaData(StaticCompilationMetadataKeys.RECEIVER_OF_DYNAMIC_PROPERTY, val);
            // end
        }

However, if I edit the example only slightly, the error is still present for "owner.protectedField", "thisObect.protectedField" and "this.protectedField". So I don't think this is a complete solution.

package a
class A {
  protected String field
}

package b
class B extends a.A {
  @groovy.transform.CompileStatic
  void method() {
    'whatever'.with {
      println field // add "owner.", "thisObect." or "this." and get an error (on line -1 no less)
    }
  }
}

Thanks for your reviewing the PR. I will try to tweak it later.

@eric-milles The PR can support your edited version of tests now.
P.S. the PR does not change the default resolve strategy

I need some time to run some experiments. There is an interplay between StaticTypeCheckingVisitor.checkOrMarkInnerPropertyOwnerAccess, VariableExpressionTransformer.tryTransformDelegateToProperty and StaticTypesCallSiteWriter.makeGetPropertySite that is quite complicated. We have made a series of changes to address some bugs and I need to go back and see what the original problems were so I can understnad the delegation metadata and property transformations.

Also, I posted links to a number of open bugs related to forbidden access errors under SC. I think there is more going on than just protected superclass field access.

Also, I posted links to a number of open bugs related to forbidden access errors under SC. I think there is more going on than just protected superclass field access.

@eric-milles I added some tests about accessing public, package-private and private(via getter) field, you can find them in this PR too.

I've tried a few things and added some test cases. Can you try just your new tests against the current master branch? I chose to roll back the fix for GROOVY-7996 since it has caused this issue and a number of others. I'd rather take a fresh look at that instead of adding one more patch on top of it's delegation data changes.

OK. I will try later today. It's 1:00 a.m. in Shanghai, I have to sleep now.

Running tests based on the latest master(last commit is: 81ef58e ), 7 tests failed:

As master reverted some commit, the PR is replaced with #1048