[External] : Re: Error examples page

Thu Nov 10 22:21:42 UTC 2022

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/43e495d0/attachment-0001.htm>