RFR: 8301580: Error recovery does not clear returnResult

[Vicente Romero]

On Wed, 1 Feb 2023 12:00:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Considering code like:
> 
> class C {
>     void m
>     {
>         return;
>     }
> }
> 
> 
> `void m` is wrapped in an erroneous tree (which is good), and if/when `Attr` is processing it in `visitErroneous`, it will create a new `Env` to attribute the erroneous part.
> 
> But, `Attr` will set a `returnResult` into the `Env`'s info - and that info is shared with the outter `Env`, so there will be a `returnResult` set after `visitErroneous`. `{ return ; }` is interpreted as an initializer, and there should be an error for the `return` there, but this error is missing, due to the set `returnResult`. This will then fail later in `Flow` with an exception:
> 
> 
> $ javac -XDshould-stop.at=FLOW -XDdev /tmp/C.java

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5222:

> 5220:     public void visitErroneous(JCErroneous tree) {
> 5221:         if (tree.errs != null) {
> 5222:             Env<AttrContext> errEnv = env.dup(env.tree);

question: shouldn't we do: `env.dup(node, env.info.dup());` instead, that way both env's won't share the info?

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

PR: https://git.openjdk.org/jdk/pull/12361