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

[Liam Miller-Cushon]

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/

On Tue, Mar 26, 2019 at 11:40 AM Jonathan Gibbons <
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/
>
> On Fri, Mar 15, 2019 at 11:26 AM Jonathan Gibbons <
> 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>
>> 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/be4ddb9c/attachment.html>