Integrated: 8308637: AssertionError when using Trees.getScope in plug-in
Jan Lahoda
jlahoda at openjdk.org
Mon Feb 23 09:46:27 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`.
This pull request has now been integrated.
Changeset: c065f411
Author: Jan Lahoda <jlahoda at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/c065f4119a527789fbe86494b068ab487a59d801
Stats: 126 lines in 2 files changed: 115 ins; 5 del; 6 mod
8308637: AssertionError when using Trees.getScope in plug-in
Reviewed-by: vromero
-------------
PR: https://git.openjdk.org/jdk/pull/29739
More information about the compiler-dev
mailing list