[External] : Re: Error examples page
Jonathan Gibbons
jonathan.gibbons at oracle.com
Thu Nov 10 22:36:04 UTC 2022
Thanks for all the extra info.
Yes, the desire for JLS references was primarily for some of the more
obscure messages about generic types, and bounds checking, etc.
Giving advice about how to fix code is definitely a challenge. Bad or
incorrect advice is arguably worse than no advice at all. Generally, the
policy for javac over the past few years has been to provide more
specific details about what is wrong, and the general context of the
error, but stopping short of suggesting changes. IDEs have arguably
more context to do it better, providing GUI support for "suggestions" on
how to change the code.
-- Jon
On 11/10/22 2:21 PM, Ethan McCue wrote:
> I think for the JLS justification in particular - that is something
> which fits within the "info" part of our model but also isn't
> particularly interesting for the target audience of "people who
> trigger compiler errors."
>
> A motivating example I sent to Vicente (almost 9 months ago! God I'm
> unproductive) was the contrast between the information conveyed in
> this message
>
> import java.util.List;
>
> enum Ex {
> A,
> B
> }
>
> public class MyClass {
> public static void main(String args[]) {
> var ex = B;
> }
> }
>
>
>
> /MyClass.java:10: error: cannot find symbol
> var ex = B;
> ^
> symbol: variable B
> location: class MyClass
>
> As compared to that emitted by rustc
>
> enum Ex {
> A,
> B
> }
>
> pub fn main() {
> let ex = A;
> }
>
> error[E0425]: cannot find value `A` in this scope
> --> src/main.rs:7:14
> |
> 7 | let ex = A;
> | ^ not found in this scope
> |
> help: consider importing this unit variant
> |
> 1 | use crate::Ex::A;
> |
>
> For more information about this error, try `rustc --explain E0425`.
>
> Which could look like (ignoring the finer details of the ascii art)
>
> error[E0123]: cannot find symbol `A` in this scope
> --> src/Main.java:9:18
> |
> 9 | var ex = B;
> | ^ not found in this scope
> |
> help: consider importing this enum variant
> |
> 1 | import static Ex.B;
> |
>
> For more information about this error, try `javac --explain E0123`.
>
> Where it is not enough to just "make a better message." There are
> structural deficiencies which preclude giving this sort of feedback.
>
> The *desire* to give a hint on how to fix something or extra context
> on why something is an error is what I think the true monster hiding
> under the bed of JDK-6397027 was. Language kinda has to be irregular
> in order to contain multiple of these semantic elements - y'know?
>
> (sorry if this isn't the most complete justification)
>
> ---
>
> My strategy for making progress has been to recruit the help of some
> students for whom working out a prototype is their senior design
> project. It's slow going, but we're all learning.
>
> On Thu, Nov 10, 2022, 4:40 PM Ethan McCue <ethan at mccue.dev> wrote:
>
> Pithy instant response: it's not too big for mainstream rustc
>
>
> On Thu, Nov 10, 2022, 4:31 PM Jonathan Gibbons
> <jonathan.gibbons at oracle.com> wrote:
>
>>
>> Our current brain scratcher is how to represent suggestions
>> on how to fix code that actually "makes the correction for them"
>>
>> So like
>>
>> int assert;
>>
>> How to model some code that can be later formatted as a
>> suggestion to rename the "assert" variable to "assert_"
>>
>>
>>
> While it sounds fun, it also sounds "too big" for mainstream
> javac. That suggests there could be a plugin mechanism to
> add more info to diagnostics. Maybe.
>
> -- Jon
>
>
>
> On 11/10/22 11:42 AM, Ethan McCue wrote:
>> Thanks - we have been tracking the PR. It will be helpful for
>> us to track our progress.
>>
>> ---
>>
>> To springboard into something different but related:
>>
>> We have been working on modeling how to add kinds of
>> information to JCDiagnostics that are semantically different
>> from a message as produced by DiagnosticInfo.
>>
>> In the current hypothesis there are two new categories of
>> information we are calling "help" and "info".
>>
>> "help" contains some suggestions on how to rectify a given
>> sort of error. In the simplest form this is a codification of
>> the "try using --enable-preview" type messages which exist
>> somewhat ad-hoc throughout the codebase.
>>
>> Our current brain scratcher is how to represent suggestions
>> on how to fix code that actually "makes the correction for them"
>>
>> So like
>>
>> int assert;
>>
>> How to model some code that can be later formatted as a
>> suggestion to rename the "assert" variable to "assert_"
>>
>>
>>
>>
>>
>> On Thu, Nov 10, 2022, 2:25 PM Jonathan Gibbons
>> <jonathan.gibbons at oracle.com> wrote:
>>
>> As a followup, the code to generate diags-examples.html
>> needed some TLC, and was fixed in JDK-8296137
>> <https://bugs.openjdk.org/browse/JDK-8296137>.
>>
>> The command to generate the report is effectively this:
>>
>> JAVA_HOME=$JDK $ANT \
>> -Dlangtools.jdk.home=$JDK \
>> -f make/langtools/diags-examples.xml
>>
>> where:
>>
>> * the current directory is the root of the OpenJDK repo
>> * ANT refers to a recent executable for Ant,
>> * JDK refers to a build of JDK in the same repo
>> containing the examples directory
>>
>> The report will be written to build/langtools/diags-examples/
>>
>> -- Jon
>>
>> On 10/3/22 1:22 PM, Jonathan Gibbons wrote:
>>>
>>> It's generated by the code in
>>> open/test/langtools/tools/javac/diags/.
>>>
>>> There are various classes there, like RunExamples.java,
>>> CheckExamples.java etc. You are probably looking for
>>> RunExamples.java; there are comments in the code on how
>>> to use it.
>>>
>>> -- Jon
>>>
>>> On 10/3/22 7:31 AM, Ethan McCue wrote:
>>>> Hey all,
>>>>
>>>> My group stumbled upon this page with a bunch of error
>>>> examples in a nice presentable format.
>>>>
>>>> https://cr.openjdk.java.net/~jjg/diags-examples.html
>>>>
>>>> My suspicion is that this was generated by something in
>>>> the codebase - if so does anyone know the command of
>>>> the top of their head?
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20221110/eaa37e9a/attachment-0001.htm>
More information about the compiler-dev
mailing list