`--explain` should disambiguate nonexistent from underdocumented error codes

[zackmdavis]

The --explain EXXX functionality (does anyone still uses this now that it's no longer advertised so hard?) gives the same "no extended information" message for real error codes that don't have a "long" explanation written, and nonexistent codes. These messages should be disambiguated (as "no extended information for E0XXX" vs. "E0XXX does not exist" or similar).

$ rustc --explain E0489 # "type/lifetime parameter not in scope here"
error: no extended information for E0489

$ rustc --explain E9999nonexisting
error: no extended information for E9999nonexisting

---

I thought this would be straightforward to implement: we do keep track of codes without explanations (which get successfully plumbed through to the error index, although the CSS hides them), only to throw that information away when macroexpanding the arrays that ultimately stock the --explain functionality. So this should, you would think, just be a matter of editing expand_build_diagnostic_array to give us a [(&str, Option<&str>)] of code–maybe-explanation pairs instead of a [(&str, &str)] of code–explanation pairs, editing errors::Registry reflect that, and making the driver care.

But when I actually do this (zackmdavis/rust@048dde26e) ... my changes to expand_build_diagnostic_array seem to have absolutely no effect (!?!); we still get a [(&str, &str)] even though I thought my code pretty clearly said otherwise, on more than one day that I've looked at this. I hereby give up in despair, bafflement, and tears.

This issue has been assigned to @jakevossen5 via this comment.

[Mark-Simulacrum]

The diagnostic registration is "just" a macro_rules macro now so I suspect this is pretty simple to implement per the suggested path in the issue description; I'm going to mark as E-easy and E-mentor with myself as the mentor.

You'll want to edit the DIAGNOSTICS array definitions here to have the type (&str, Option<&str>) or so and add in the short diagnostics.

Once that's done, if you run ./x.py check you'll likely hit an error in the use site of DIAGNOSTICS from all the crates. Fixing that'll mostly involve fixing up the diagnostics registry in librustc_errors; I would store the long diagnostics and short diagnostics separately, adding a field like short_descriptions: FxHashSet<&'static str>.

Once this is done, there might be a few more type errors to clean up but that should mostly be a matter of making types match up I would hope.

Let me know if you have any questions; here on this issue or feel free to open up a PR with some initial work and I can try and provide feedback there.

[Mark-Simulacrum]

One additional thing that we should probably add as part of this work is an error if the same diagnostic code is registered twice (cc #64426). I imagine this would mostly be a matter of inserting all the codes into an FxHashSet and panicking if there's one inserted twice; an ICE here is fine since it'll definitely be caught in CI.

[jakevossen5]

Hey,

If this still needs fixed, I would love to work on this. I will probably be reaching out before to long for some guidance.

@rustbot claim

[jakevossen5]

Shoot not sure if I read what was happening in this thread all the way. @zackmdavis are you working on this already?

[zackmdavis]

@jakevossen5 I'm not; go for it! (Although ... I thought I remembered seeing an issue recently where people were discussing moving away from the numeric error codes, but I can't find it. @estebank, was that a real thing?)

[jakevossen5]

Maybe you are referring to this conversation on Zulip? https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/get.20rid.20of.20error.20codes