Children diagnostics with messages not fully displayed

[Xanewok]

Diagnostics emitted by rustc are very flexible and can contain associated messages and spans.

Currently the emitted JSON format consists of the primary diagnostic, possibly having multiple spans, which can also contain labels, but also children/secondary diagnostics, each having its main message and multiple spans, just like the primary diagnostic.

Currently the spans are all flattened and LSP diagnostics are created for them if they have labels, however that doesn't work for E0495. These consist of children diagnostics with a specified message and a single span, which does not have a label. This means that we don't create separate diagnostics and the children messages are ignored.

Ideally, in this case these should be treated just as spans with labels, for which we emit additional diagnostic, and for which notes should not be included in the main message.

[alexheretic]

We can shove the E0495 json message into a file in test_data/compiler_message and start to tdd what we want out of it along with the other tests in post_build.rs.

Do you think the best translation of this diagnostic involves anything new, or can we cover it with additional secondaries?

[Xanewok]

I'd like to work on it after #848 merges, which slightly changes how we translate diagnostics.

To minimize branching and treating it as a special case, I think it'd be convenient to pre-process the deserialized diagnostics and then do the translation.

One idea might be to convert every child diagnostic with a single (should it also work with multiple?) labelless span to a secondary span in the main diagnostic with the child diagnostic message set as a label.

This would stop them from being included as notes in the primary emitted diagnostic, since most of them either literally mention a span in the message or refer to it in JSON, so it'd be better to just emit secondary/related diagnostics for those using the established mechanism.

[Xanewok]

A prototype can be found here.

While this seems to be working pretty good for related information-enabled clients, it probably needs some more work. Not sure if we can just treat children message with a single span as a secondary span - it seems to create more noise. Maybe we shouldn't include notes with diagnostics originating from secondary spans?