RFR: 8220632: Suggest recompiling with a larger value of -Xmaxerrs/-Xmaxwarns if diagnostics were suppressed

[Jonathan Gibbons]

OK ... but with a trivial style issue.

In the test-description comment block, the one beginning @test, the 
recommended style is to not start the comment with "/**" because it is 
not a documentation comment.

Fix that and you're good to go.

-- Jon


On 03/26/2019 05:47 PM, Liam Miller-Cushon wrote:
> Thanks, I updated the patch to use your text.
>
> I also remembered to update CheckExamples, and fixed a bug I 
> introduced moving this patch around earlier:
>
> diff -r 491d5bc43f86 
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java 
> Tue Mar 26 16:09:33 2019 -0700
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java 
> Tue Mar 26 16:57:37 2019 -0700
> @@ -723,13 +723,14 @@
>                  break;
>              case ERROR:
> -                if (nerrors < MaxErrors &&
> - (diagnostic.isFlagSet(DiagnosticFlag.API) ||
> -                     shouldReport(diagnostic))) {
> -                    writeDiagnostic(diagnostic);
> -                    nerrors++;
> -                } else {
> -                    nsuppressederrors++;
> +                if (diagnostic.isFlagSet(DiagnosticFlag.API) ||
> +                     shouldReport(diagnostic)) {
> +                    if (nerrors < MaxErrors) {
> +                        writeDiagnostic(diagnostic);
> +                        nerrors++;
> +                    } else {
> +                        nsuppressederrors++;
> +                    }
>                  }
>                  break;
>              }
>
> The (hopefully final) version of the webrev is here:
> http://cr.openjdk.java.net/~cushon/8220632/webrev.02/ 
> <http://cr.openjdk.java.net/%7Ecushon/8220632/webrev.02/>
>
> On Tue, Mar 26, 2019 at 11:40 AM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     OK, with a suggestion.
>
>     The basic update is OK.  Seeing the messages in context, I would
>     suggest to tweak the messages as follows:
>
>     1640 compiler.misc.count.error.recompile=\
>     1641 only showing the first {0} errors, of {1} total; use
>     -Xmaxerrs if you would like to see more
>
>     I like the text for explicitly hinting at why you might want to
>     use the option, as compared to just telling people to consider
>     using the option, without saying why.
>
>     No need to re-review if you keep the webrev as is, or change to
>     the suggested text, for both messages
>
>     -- Jon
>
>     On 03/15/2019 11:31 AM, Liam Miller-Cushon wrote:
>>     I updated the webrev with the suggested changes to the diagnostic
>>     text:
>>
>>     http://cr.openjdk.java.net/~cushon/8220632/webrev.01/
>>     <http://cr.openjdk.java.net/%7Ecushon/8220632/webrev.01/>
>>
>>     On Fri, Mar 15, 2019 at 11:26 AM Jonathan Gibbons
>>     <jonathan.gibbons at oracle.com
>>     <mailto:jonathan.gibbons at oracle.com>> wrote:
>>
>>
>>         On 3/15/19 11:21 AM, Liam Miller-Cushon wrote:
>>>         On Fri, Mar 15, 2019 at 11:11 AM Ron Shapiro
>>>         <ronshapiro at google.com <mailto:ronshapiro at google.com>> wrote:
>>>
>>>             Regarding Jonathan's comments in the bug, would it be
>>>             helpful/possible to categorize the types of diagnostics
>>>             not shown? For built-in diagnostics we could try to
>>>             group (maybe just the popular ones?) by their key?
>>>
>>>             42 symbols could not be found
>>>             15 errors from com.example.proc.ExampleProcessor
>>>             etc
>>>
>>>             ?
>>>
>>>
>>>         It's certainly possible. I think we want to strike a balance
>>>         between providing enough information to help avoid users
>>>         getting stuck when diagnostics are suppressed, but not so
>>>         much information that it's distracting (since hopefully in
>>>         the common case the suppressed diagnostics are not necessary
>>>         to understand the problem).
>>>
>>>         In that specific example, Jon's suggestion to sort the
>>>         non-recoverable diagnostics first (which I intend to follow
>>>         up on JDK-8220691) would avoid suppressing the
>>>         com.example.proc.ExampleProcessor diagnostics entirely.
>>
>>
>>         If we were to provide this extra info, maybe it could/should
>>         be opt-in.  But, I think it is a better use of resources to
>>         make javac more friendly "out of the box" and to print the
>>         more-likely-important messages first, so that users don't
>>         have to wade through too much info.
>>
>>         -- Jon
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190328/b6800617/attachment-0001.html>