Change:
use rustc_codegen_utils::codegen_backend::CodegenBackend; use rustc_data_structures::profiling::print_time_passes_entry; use rustc_data_structures::sync::SeqCst; <del> use rustc_errors::{registry::Registry, PResult}; </del> <ins> use rustc_errors::{ registry::{InvalidErrorCode, Registry}, PResult, }; </ins> use rustc_feature::{find_gated_cfg, UnstableFeatures}; use rustc_hir::def_id::LOCAL_CRATE; use rustc_interface::util::{collect_crate_types, get_builtin_codegen_backend};

Discussion:
The functionality (does anyone still uses this now that it's ?) 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). I thought this would be straightforward to implement: we (which get successfully , although the ), only to when macroexpanding the arrays . So this should, you would think, just be a matter of editing reflect that, and making the care. But when I actually do this (zackmdavis/rust ... my changes to seem to have absolutely no effect (!?!); we still get a 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. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The diagnostic registration is "just" a macrorules 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 array definitions to have the type or so and add in the short diagnostics. Once that's done, if you run you'll likely hit an error in the use site of from . Fixing that'll mostly involve fixing up the diagnostics registry in ; I would store the long diagnostics and short diagnostics separately, adding a field like . 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.
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 ).

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.
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. claim
Shoot not sure if I read what was happening in this thread all the way. are you working on this already?
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. was that a real thing?)
Maybe you are referring to this conversation on Zulip? https://rust-