RFR: JDK-8248641: Trees.getScope returns incorrect results for code inside a rule case
jan.lahoda at oracle.com
Mon Jul 27 12:46:52 UTC 2020
The existing patch is always filling out the JCCase.body, even for
statement cases (unlike the parser, which leaves the body empty/null for
statement cases). While I don't think there's anything directly broken
by this, it may be better to keep JCCase.body null for statement cases
to keep consistency with the normal non-copied trees.
What do you think?
On 07. 07. 20 21:15, Vicente Romero wrote:
> looks good,
> On 7/2/20 9:11 AM, Jan Lahoda wrote:
>> When calling Trees.getScope for a TreePath that is inside a rule case
>> (i.e. "case ->"), the results are wrong/do not reflect the elements
>> declared inside the enclosing method.
>> The reason is that, for rule cases, JCCase tree is keeping "body",
>> which represents what is in the source code. And this body is wrapped
>> and put into "stats", which are basically the statements for an
>> ordinary case. This means that javac can typically only work over the
>> "stats". When TreeCopied copies the JCCase tree, it will duplicate
>> both "stats" and "body" separately, leading to a duplication in trees.
>> And then Attr.breakTree points to the requested tree from "body", but
>> that one is never attributed, and so the appropriate scope is never
>> The proposed patch here is to only duplicate "stats", and then take
>> appropriate "body" from "stats", leading to only one copy of the tree.
>> How does this look?
More information about the compiler-dev