RFR: 8308637: AssertionError when using Trees.getScope in plug-in

Vicente Romero vromero at openjdk.org
Thu Feb 19 17:36:07 UTC 2026


On Mon, 16 Feb 2026 10:50:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The Trees API has a method to get information about elements available at a given place in the source code: `Trees.getScope(TreePath)`. It works by duplicating a piece of the AST, passing it to `Attr`, and stopping the attribution at the point specified by the `TreePath`, returning the current `Env` at that point.
> 
> For code like:
> 
> class B {
>     public class Test {}
>     void m() {
>         new Test() {};
>         this.new Test() {};
>     }
> }
> 
> 
> when the TreePath is pointing at `Test` in `this.new Test`, this does not work very well for two reasons:
> - when attributing the NewClassTree with enclosing expression, `Attr` is not really attributing the `Test` tree, but it synthetizes a temporary qualified name and attributes this synthetized name. The attribution then does not stop properly. This can be fixed by adding a check to stop the attribution at the appropriate place.
> - if the enclosing classes are not-yet attributed, attributing the anonymous body for `new Test() {};` will trigger attribution of `Test`, which will trigger an attribution of `B`, and that will try to re-attribute the original method `m`. This is attributing the conceptually same method (with same local classes) twice, which leads to problems downstream. The proposal is to avoid superclass and enclosing class attribution when evaluating `Scope`.

test/langtools/tools/javac/api/TestGetScopeResult.java line 1052:

> 1050:                                 @Override
> 1051:                                 public Void visitIdentifier(IdentifierTree node, Void p) {
> 1052:                                     //                                if (getCurrentPath().getParentPath().getLeaf().getKind() == Kind.NEW_CLASS) {

can we remove this comment?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29739#discussion_r2829182038


More information about the compiler-dev mailing list