b869e84e58
errors: generate typed identifiers in each crate Instead of loading the Fluent resources for every crate in `rustc_error_messages`, each crate generates typed identifiers for its own diagnostics and creates a static which are pulled together in the `rustc_driver` crate and provided to the diagnostic emitter. There are advantages and disadvantages to this change.. #### Advantages - Changing a diagnostic now only recompiles the crate for that diagnostic and those crates that depend on it, rather than `rustc_error_messages` and all crates thereafter. - This approach can be used to support first-party crates that want to supply translatable diagnostics (e.g. `rust-lang/thorin` in https://github.com/rust-lang/rust/pull/102612#discussion_r985372582, cc `@JhonnyBillM)` - We can extend this a little so that tools built using rustc internals (like clippy or rustdoc) can add their own diagnostic resources (much more easily than those resources needing to be available to `rustc_error_messages`) #### Disadvantages - Crates can only refer to the diagnostic messages defined in the current crate (or those from dependencies), rather than all diagnostic messages. - `rustc_driver` (or some other crate we create for this purpose) has to directly depend on *everything* that has error messages. - It already transitively depended on all these crates. #### Pending work - [x] I don't know how to make `rustc_codegen_gcc`'s translated diagnostics work with this approach - because `rustc_driver` can't depend on that crate and so can't get its resources to provide to the diagnostic emission. I don't really know how the alternative codegen backends are actually wired up to the compiler at all. - [x] Update `triagebot.toml` to track the moved FTL files. r? `@compiler-errors` cc #100717 |
||
|---|---|---|
| .. | ||
| locales | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
For more information about how rustc works, see the rustc dev guide.