-proceedOnError option (like ECJ) ?
Mickael Istria
mistria at redhat.com
Fri Nov 22 21:47:04 UTC 2024
Hello,
I'd like to share soe further "progress" (and lack of) on this topic and
some further considerations.
First, we managed to get this to work for a particular case through our
consumer code: we can override the Gen.visitErroneous and Gen.visitExec
methods to generate the bytecode of `throw new
RuntimeException("Compilation error")` instead of crashing. And I could see
that the generate .class throw the exception when expected. So that's very
encouraging.
However this is unfortunately too restricted: one more generic idea is to
override the `Gen.genExpr(...)` method so that is the expression is
JCErroneous or type is null, then we generate the bytecode for `throw new
RuntimeException("Compilation Error")`. But the issue is that one cannot
really override `genExpr` because it returns an object of the
package-visible only Item type, so we can simply not override it. We've
tried to greedily duplicate most of the com.sun.tools.javac.jvm package but
the "Code" type which is used by Symbol but still has some important nested
types that are not open make that even duplicating the code in the package
is diffcult.
So implementation-wise, I think we are getting close to a conclusion that
fully providing such ability through consumer code is for the moment about
impossible. Changes seems necessary in openjdk directly.
On that matter, we came to learn about `should-stop.ifError` and it seems
that in case `should-stop.ifError=GENERATE` then generating the class for
erroneous .java files similarly to what we suggest above is a fair
expectation, isn't it? That would mean that basically, there would be no
need for a new flag, nor a new option, and we'd "just" have to fix the
currently crashing bits of javac?
If anyone has further suggestions to experiment, they are for sure welcome!
Cheers,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241122/7e2290e6/attachment.htm>
More information about the compiler-dev
mailing list