RFR: JDK-8239544 : Javac does not respect should-stop.ifNoError policy to stop after CompileState PARSE, ENTER and PROCESS

[Adam Sotona]

I'll fix the formatting
Thank you,
Adam

> On 23 Mar 2020, at 16:50, Jim Laskey <james.laskey at oracle.com> wrote:
> 
> I think coding standards recommend
> 
> 
> 950 
> 	 if (!CompileState.ATTR.isAfter(shouldStopPolicyIfNoError)) switch (compilePolicy) {
> 
> 	 if (!CompileState.ATTR.isAfter(shouldStopPolicyIfNoError)) {
> 		switch (compilePolicy) {
> 
> 	...
> 	}
> 
> otherwise +1
> 
> 
> 
> 
>> On Mar 23, 2020, at 12:44 PM, Adam Sotona <adam.sotona at oracle.com <mailto:adam.sotona at oracle.com>> wrote:
>> 
>> Hi,
>> I would like to ask you for review of the JavaCompiler patch fixing its response to should-stop.ifNoError= option for PARSE, ENTER and PROCESS compiler states.
>> The patch also includes new T8239544.java matrix regression test validating the compiler really stops at the requested states even under various compiler policies.
>> The most critical part of the fix was to do not affect existing (golden-file) tests expecting exact compiler errors and also do not affect MultiTaskListener expected behavior (and related tests).
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8239544 <https://bugs.openjdk.java.net/browse/JDK-8239544>
>> webrev: http://cr.openjdk.java.net/~asotona/8239544/webrev.00/ <http://cr.openjdk.java.net/~asotona/8239544/webrev.00/>
>> 
>> Mach5 build passed Tier1, Tier2 and Tier3 tests
>> 
>> Thank you,
>> Adam
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20200324/d7462820/attachment.htm>