[Investigation] The relationship between the compile policies and the stop policies

[Guoxiong Li]

Hi all,

When I read the code of the
`com.sun.tools.javac.main.JavaCompiler#JavaCompiler(Context context)`, I
found the following strange code.

```
        if (options.isSet("should-stop.at") &&
            CompileState.valueOf(options.get("should-stop.at")) ==
CompileState.ATTR)
            compilePolicy = CompilePolicy.ATTR_ONLY;
        else
            compilePolicy =
CompilePolicy.decode(options.get("compilePolicy"));
```

It means that if the `should-stop.at` is `ATTR`, the compile policy will be
`ATTR_ONLY`. It may be not right. Because `should-stop.at` is the same as
`should-stop.ifError`. If no error occurs, the compilation should continue.
But the `ATTR_ONLY` means that the compilation always finishes after
`ATTR`. Therefore, I think the `should-stop.at=ATTR` is not equal to
`compilePolicy=ATTR_ONLY`.

I searched the submit log of these code. I found these codes were submitted
at JDK-8148808 [1]. Please see the following snippet of the patch[2]
of JDK-8148808.

```

-        attrParseOnly = options.isSet("-attrparseonly");
<http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.22>
        encoding      = options.get(ENCODING);
<http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.23>
        lineDebugInfo = options.isUnset(G_CUSTOM) ||
<http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.24>
                        options.isSet(G_CUSTOM, "lines");
<http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.25>@@
-405,7 +403,8 @@
<http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.26>
 <http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.27>
        verboseCompilePolicy = options.isSet("verboseCompilePolicy");
<http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.28>
 <http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.29>-
       if (attrParseOnly)
<http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.30>+
       if (options.isSet("shouldStopPolicy") &&
<http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.31>+
           CompileState.valueOf(options.get("shouldStopPolicy")) ==
CompileState.ATTR)
<http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.32>
            compilePolicy = CompilePolicy.ATTR_ONLY;
<http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.33>
        else <http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07#l5.34>
            compilePolicy =
CompilePolicy.decode(options.get("compilePolicy"));

```

It removed the option `-attrparseonly` and used `shouldStopPolicy` to
replace `-attrparseonly`.(FYI: `shouldStopPolicy` was changed to `
should-stop.at` in another patch.)
Based on the logic of the code above, the original developer might think
that the following two expressions are the same:

*1. options.isSet("-attrparseonly")*
*2. options.isSet("shouldStopPolicy") *
*    && CompileState.valueOf(options.get("shouldStopPolicy")) ==
CompileState.ATTR)*

Actually it is not the same. The first expression may be same as the
following expression:

*options.isSet("should-stop.ifError") *
*&& CompileState.valueOf(options.get("should-stop.ifError")) ==
CompileState.ATTR)*
*&& options.isSet("should-stop.ifNoError") *
*&& CompileState.valueOf(options.get("should-stop.ifNoError")) ==
CompileState.ATTR)*

Anyway, I don't think it is a good idea to mix the compile policies and the
stop policies. So we should only keep this line:

```
            compilePolicy =
CompilePolicy.decode(options.get("compilePolicy"));
```

and remove the following codes:

```
        if (options.isSet("should-stop.at") &&
            CompileState.valueOf(options.get("should-stop.at")) ==
CompileState.ATTR)
            compilePolicy = CompilePolicy.ATTR_ONLY;
        else
```

What's your opinion? Especially, should we mix the compile policies and the
stop policies? Should there be a relationship between the compile policies
and the stop policies?
Any idea is appreciated. Thank you.

[1] https://bugs.openjdk.java.net/browse/JDK-8148808
[2] http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/645b5debcb07

Best Regards,
-- Guoxiong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210509/03efbce4/attachment.htm>