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

[Jonathan Gibbons]

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/20190326/d6bf1984/attachment.html>