-proceedOnError option (like ECJ) ?

[Jan Lahoda]

Hello Mickael,


Without commenting on desirability of this feature for OpenJDK or any 
particular project, and as my personal opinion.


In a very simplified view, javac (as is common) has a front-end and a 
back-end. The front-end parses and analyzes the source, and reports most 
errors, producing an attributed AST; the back-end then 
transforms/simplifies the AST and generates the classfiles. The 
front-end currently ends with Flow, and the back-end currently starts 
with TransTypes. I have doubts it is realistically feasible to take the 
AST for the erroneous code through the back-end. It may be much simpler 
to fix the AST by replacing the erroneous parts with the exceptions at 
the boundary between the front-end and the back-end, hence the back-end 
would only work on AST which represents non-erroneous code. This is 
actually what NetBeans is doing (both in the current, and historical 
implementation of this feature).


Jan


On 22. 11. 24 22:47, Mickael Istria wrote:
> 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,