Be consistent about whether the span label duplicates info in an error message

[nrc]

Often an error message has two parts - the heading and a label on a span. E.g.,

error[E0425]: cannot find value `labe` in this scope
   --> src/actions/compiler_message_parsing.rs:116:30
    |
116 |             message.push_str(labe);
    |                              ^^^^ did you mean `label`?

Here the heading is cannot find value labe in this scope and the label on the span is did you mean label? In this case the two contain different information.

However, in some cases, the info is duplicated, e.g.,

error[E0061]: this function takes 1 parameter but 0 parameters were supplied
   --> src/actions/compiler_message_parsing.rs:116:21
    |
116 |             message.push_str();
    |                     ^^^^^^^^ expected 1 parameter

This is a problem for IDEs because all errors are on spans and we must choose to either show both pieces of text (which looks weird and redundant in the second example) or just the heading (which elides information in the first example).

Alternatively, we could add some flag to the JSON error structure to indicate whether a label is redundant or not.

cc @jonathandturner

[Mark-Simulacrum]

Nominating for compiler discussion (though perhaps this is a dev tools question?). We should decide on this sooner rather than later, since new diagnostics or updates to past ones should take it
into account.

[nikomatsakis]

Yeah, this is a tricky one. I think I've come to prefer that the main error message be somewhat generic, without a lot of specific detail, and that we give the specific detail in labels. But that's a mildly separate question I guess.

[nikomatsakis]

To clarify what I meant, the message that @nrc gave might be:

error[E0061]: wrong number of parameters supplied
   --> src/actions/compiler_message_parsing.rs:116:21
    |
116 |             message.push_str();
    |                     ^^^^^^^^ expected 1 parameter, found 0 parameters

Here the "error" part is fairly generic, and the details are in the body.

[nikomatsakis]

cc @rust-lang/dev-tools @rust-lang/docs -- thoughts?

[nagisa]

We cannot get rid of the proper error messages, because we also have the different “non-pretty” error output styles which have to present all the relevant information.

The solution from the implementation standpoint would be having “structured” errors. As in, each error would be a proper structure describing the error, rather than a collection of strings; the presentation layer then would figure out how to present each of the errors properly itself.

[oli-obk]

We could go half way to structured errors by only making this case explicit in the diagnostics structures and api