Error count propagation between rounds

[Werner Dietl]

Jon,

thanks for that update.
This sounds like you agree that the behavior I described with Java 7
is incorrect and should be fixed.
Will somebody from the javac group suggest a better fix than what I
did in type-annotations?

Thanks,
cu, WMD.

On Mon, Nov 12, 2012 at 12:05 PM, Jonathan Gibbons
<jonathan.gibbons at oracle.com> wrote:
> Currently, the policy is that unrecoverable errors should be reported, and
> go to the error count.  They should cause round processing to stop.  It may
> be the case that some errors are reported twice, which would be a bug,
> separate from the total number of bugs reported.
>
> Recoverable errors should be suppressed, and do not terminate round
> processing.
>
> Generally speaking, only "name not found" errors are classified as
> recoverable errors, since they may be generated by additional rounds of
> processing.
>
> -- Jon
>
>
>
> On 11/12/2012 11:11 AM, Werner Dietl wrote:
>>
>> Dear all,
>>
>> in one of my recent pushes, in particular, in:
>>
>>
>> http://hg.openjdk.java.net/type-annotations/type-annotations/langtools/rev/b7f384a554b3
>>
>> I introduced that the nerrors information is propagated between rounds.
>>
>> This fixed three test case errors I've been having, but also
>> introduced 19 new ones.
>> I would like to discuss what the best solution to this issue is.
>>
>> To illustrate my point, let us take stock Java 7 (javac 1.7.0_09) and
>> JDK 8 Build b63 and the two attached files, which are based on
>> langtools/test/tools/javac/api/6406133.
>>
>> (I ignore the single warning that is caused by the processor version
>> mismatch. The result is the same if I adapt the version number for
>> each compiler.)
>>
>> Let's first compile the processor, without output:
>> javac SimpleProc.java
>>
>> Then, let's normally compile file Erroneous.java:
>> $ javac Erroneous.java
>> Erroneous.java:2: error: cannot find symbol
>> class A extends Missing {
>>                  ^
>>    symbol: class Missing
>> 1 error
>>
>> I would say that's the expected output.
>>
>> Now, let's add the annotation processor:
>>
>> $ javac -processor SimpleProc Erroneous.java
>> Processing: [java.lang.Deprecated]
>> Processing: []
>> Erroneous.java:2: error: cannot find symbol
>> class A extends Missing {
>>                  ^
>>    symbol: class Missing
>> Erroneous.java:2: error: cannot find symbol
>> class A extends Missing {
>>                  ^
>>    symbol: class Missing
>> 1 error
>>
>> Isn't it strange that we get two error outputs and just one error count?
>> The return value $? is 1, which is expected for an error.
>>
>> Finally, if we compile with "-proc:only" we get:
>>
>> $ javac -processor SimpleProc -proc:only Erroneous.java
>> Processing: [java.lang.Deprecated]
>> Processing: []
>> Erroneous.java:2: error: cannot find symbol
>> class A extends Missing {
>>                  ^
>>    symbol: class Missing
>>
>> We get only one error output, but suddenly no longer the "1 error"
>> output. Also, $? is 0, indicating that there was no error.
>> With -proc:only maybe semantic errors shouldn't be reported, because
>> that phase is after processing. However, then I would not expect to
>> see an error message.
>>
>> The order of the output is different between a JDK 6 and JDK 7, but
>> the basic behavior is the same.
>>
>> With JDK 8 Build b63 from Nov 1 I get the same behavior as with Java
>> 7, that is, 2 error messages but a failed compile with a processor, a
>> single error message and a successful compile with proc:only.
>>
>> With my pushed changes, we get the following behavior:
>>
>> javac -cp . -processor SimpleProc Erroneous.java
>> Processing: [java.lang.Deprecated]
>> Processing: []
>> Erroneous.java:25: error: cannot find symbol
>> class A extends Missing {
>>                  ^
>>    symbol: class Missing
>> 1 error
>> $? is 1
>>
>> javac -cp . -processor SimpleProc -proc:only Erroneous.java
>> Processing: [java.lang.Deprecated]
>> Processing: []
>> Erroneous.java:25: error: cannot find symbol
>> class A extends Missing {
>>                  ^
>>    symbol: class Missing
>> 1 error
>> $? is 1
>>
>> The difference is made by the line:
>>              this.nerrors = other.nerrors;
>> in
>> com.sun.tools.javac.util.Log.initRound(Log)
>>
>> With setting nerrors we get:
>>
>>      [jtreg] Test results: passed: 2,409; failed: 19
>>
>> Without setting nerros we get:
>>
>>      [jtreg] Test results: passed: 2,425; failed: 3
>>
>> I don't know how to better fix the 3 remaining errors without setting
>> nerrors. They are caused by executing Flow processing with an
>> inconsistent AST, resulting in NPEs.
>>
>> I think some of the 19 errors can be fixed by admitting the "x errors"
>> output in the expected file.
>> Simply setting nerrors however seems to be incorrect in general, as it
>> causes errors to be counted multiple times.
>> Is there a way to decide whether to propagate the error count or not?
>> Should -proc:only make a difference in this decision?
>>
>> All comments for how to better solve this problem would be very welcome.
>>
>> Thanks,
>> cu, WMD.
>>
>



-- 
http://www.google.com/profiles/wdietl