Repository navigation
Accumulate all error codes / descriptions into one crate? #66210
Description
@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 oflibrustcandlibsyntax, which are on the critical path when buildingrustc.
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.
Activity
GuillaumeGomez commentedon Nov 8, 2019
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 commentedon Nov 8, 2019
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.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.
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 commentedon Nov 8, 2019
That would make the whole more difficult to understand. Why would we want to separate the declaration and the explanation?
Wow, a brave one. I never use the github search; it's just useless most of the time. A
git grepworks way better. :)Centril commentedon Nov 8, 2019
Better incremental and pipe-lining with
./x.pybecause onlyrustc_interface::util::diagnostics_registryneeds 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
.mdfiles, 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 commentedon Nov 8, 2019
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.mdfiles or something that areinclude!'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 commentedon Nov 10, 2019
Then just one question remain: will this lazy linking work with libcore?
Centril commentedon Nov 11, 2019
@GuillaumeGomez Can you elaborate on that please? libcore doesn't have error codes...?
GuillaumeGomez commentedon Nov 11, 2019
Indeed, don't know why I recalled libcore having error codes...
Centril commentedon Nov 11, 2019
Assigning myself to do this at some point, but feel free to work-steal.
GuillaumeGomez commentedon Nov 11, 2019
I'll give it a try then. :)
Rollup merge of rust-lang#66456 - Centril:driver-codes, r=Mark-Simula…
Centril commentedon Jan 30, 2020
We did this.