Upstreaming: Additional information in error messages

[cpovirk]

(different from #9)

• Include class name along with method name: b7cd35c
• Plug in arbitrary information (but perhaps my current approach is overly general): 508185c [edit: used by jspecify/nullness-checker-for-checker-framework@9a44397 for ternaries], with perhaps more to come in the future

[wmdietl]

Including more information in error messages would be great.

It would seem nice to consistently quote program text in error messages, e.g. to use incompatible argument for parameter ''value'' of ''Optional.of''.

Looking through the javac error messages there is no consistent style: sometimes symbols are in quotes, sometimes not.

Plugging in configurable extra error information also seems useful, but I would like to find a more general solution that works for more than just returns. The adaptation for ternaries would probably also be useful if the ternary is used in a method argument or an assignment.

[cpovirk]

I'd be happy to see us not worry about this for now: As you say, the current approach helps only in some cases, and there is much more that we could discuss on the topic. If we're able to address the bigger issues of the de-forking first, then I'm confident that we can subsequently transition from "checker does the right thing but with sometimes confusing error messages" to "checker does the right thing with excellent error messages."

[wmdietl]

That sounds good!

Regarding the comment about the caret position: the caret points at the argument; if that argument is another method invocation, it will point at the parenthesis in that invocation. So I don't think there is much to improve there.
But let's postpone all this until after #29.

[cpovirk]

Caret placement may be hopeless :)

The current behavior is the one that is technically unambiguous, and that has a lot going for it. The problem is that we have plenty of experience with people who see...

error: blah blah blah
foo(bar())
   ^

...and naturally assume that the problem is with passing bar() to foo, rather than with doing something to the result of the foo call.

In the past 3(!) years, I think I've come around to your idea that the caret position is as good as it gets and that we need to do what we can with error messages

I wonder if we can learn from other tools. I know that Kotlin is quite bad about this in some cases but I think also decent in others.