Accumulate all error codes / descriptions into one crate?

[Centril]

@ecstatic-morse noted on Zulip that:

Is there a reason that error codes are split across crates instead of combined into a single one e.g., librustc_errors? Seems like doing so would make this easier, as well as move some code out of librustc and libsyntax, which are on the critical path when building rustc.

Should we move all the error codes into a dedicated crate (librustc_error_codes) or into the existing librustc_errors? Advantages include:

• Making other crates, especially librustc, smaller and thus improving pipelining.
• All the codes and descriptions are in a single place, which should be easier to manage overall -- no need to move error codes when logic is moved between crates or when crates are split.

Disadvantages include:

• Everything that uses error codes will need to be recompiled, in particular librustc, if you do introduce a new error code or modify a description. I don't think this happens all that frequently. We could also separate the codes from the descriptions.

cc @rust-lang/compiler @GuillaumeGomez @nnethercote

(My personal inclination is to introduce a new fresh crate dedicated to error codes.)

• Need to clean up the macro usage and maybe debate about either we want to convert all error codes to strings directly and therefore move the unused/unexistent/duplicates check into tidy.

[GuillaumeGomez]

The issue is that if you change this crate, you'll have to recompile everything everytime. I think the main reason why it hasn't been done this way is that it allows to prevent both the full re-compilation and to have HUGE files with hundreds of error codes in one place.

Also, small advantage but a nice one: it allows to quickly link an error code to where it's coming from in the code.

[Centril]

The issue is that if you change this crate, you'll have to recompile everything everytime.

Hmm; so I took a look at https://doc.rust-lang.org/nightly/nightly-rustc/src/syntax/diagnostics/macros.rs.html and it doesn't seem like there's actually an intrinsic reason why that would be the case: we could separate the registration of diagnostic codes and descriptions from the actual struct_span_err! macros that use the codes (it's just an identifier). Tidy can then make sure to catch any problems (e.g. registered but unused, used but not registered, ...). We should be able to improve recompilation actually.

and to have HUGE files with hundreds of error codes in one place.

That's fair, but note that even though the file would be large, it would also be regular and of "boring" content. The lion's share would just be a bunch of strings.

Also, small advantage but a nice one: it allows to quickly link an error code to where it's coming from in the code.

I had to do a lot of this when writing up #65324, I used the GitHub search functionality by pasting in the error code and it quickly found the usage.

[GuillaumeGomez]

That would make the whole more difficult to understand. Why would we want to separate the declaration and the explanation?

I had to do a lot of this when writing up #65324, I used the GitHub search functionality by pasting in the error code and it quickly found the usage.

Wow, a brave one. I never use the github search; it's just useless most of the time. A git grep works way better. :)

[Centril]

Why would we want to separate the declaration and the explanation?

• Better incremental and pipe-lining with ./x.py because only rustc_interface::util::diagnostics_registry needs to depend on those explanations. In fact, that function can be moved wholesale to the new crate. Also better pipe-lining because librustc and friends get thinner.

• Better potential for internationalization -- maybe we should even move these descriptions to .md files, post-process, and load them in lazily at run-time?

• Simpler dev UX: want to add an error description? there's just one place to append to instead of many more files.

[nikomatsakis]

If we do this right, the error codes crate could be "lazilly" linked -- i.e., only a dependency of librustc_driver. We could achieve this for example by using a query to fetch the details of the error code. Then there is no recompilation hazard. Ideally, the error descriptions themselves might even be in .md files or something that are include!'d in, to make them more viewable?

UPDATE: Er, right, @Centril was already proposing that md thing. I missed it in the last comment, though I saw it on Zulip. :) Well 👍 to that!

[GuillaumeGomez]

Then just one question remain: will this lazy linking work with libcore?

[Centril]

@GuillaumeGomez Can you elaborate on that please? libcore doesn't have error codes...?

[GuillaumeGomez]

Indeed, don't know why I recalled libcore having error codes...

[Centril]

Assigning myself to do this at some point, but feel free to work-steal.

[GuillaumeGomez]

I'll give it a try then. :)