-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Migrate codegen_ssa
to diagnostics structs - [Part 1]
#102612
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Migrate codegen_ssa
to diagnostics structs - [Part 1]
#102612
Conversation
r? @eholk (rust-highfive has picked a reviewer for you, use r? to override) |
cc @davidtwco, @compiler-errors, @JohnTitor, @estebank, @TaKO8Ki |
codegen_ssa
to diagnostics structs _[Part 1]_codegen_ssa
to diagnostics structs - [Part 1]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a great start, thanks!
Looks good to me, but I'll hand it off to @davidtwco to make sure he feels his comments are adequately addressed. @bors r? @davidtwco |
8d94cda
to
954a62f
Compare
This comment was marked as resolved.
This comment was marked as resolved.
7d5f50f
to
f69f1b0
Compare
f69f1b0
to
41ab94c
Compare
@bors r+ |
📌 Commit 41ab94cb00f0e08590660260d20d4ba534042a88 has been approved by It is now in the queue for this repository. |
This comment was marked as resolved.
This comment was marked as resolved.
41ab94c
to
13d4f27
Compare
@rustbot label -S-waiting-on-author +S-waiting-on-review |
@bors r+ |
…-diagnostics-structs, r=davidtwco Migrate `codegen_ssa` to diagnostics structs - [Part 1] Initial migration of `codegen_ssa`. Going to split this crate migration in at least two PRs in order to avoid a huge PR and to quick off some questions around: 1. Translating messages from "external" crates. 2. Interfacing with OS messages. 3. Adding UI tests while migrating diagnostics. _See comments below._
…-diagnostics-structs, r=davidtwco Migrate `codegen_ssa` to diagnostics structs - [Part 1] Initial migration of `codegen_ssa`. Going to split this crate migration in at least two PRs in order to avoid a huge PR and to quick off some questions around: 1. Translating messages from "external" crates. 2. Interfacing with OS messages. 3. Adding UI tests while migrating diagnostics. _See comments below._
…iaskrgr Rollup of 11 pull requests Successful merges: - rust-lang#100387 (Check uniqueness of impl items by trait item when applicable.) - rust-lang#101727 (Stabilize map_first_last) - rust-lang#101774 (Warn about safety of `fetch_update`) - rust-lang#102227 (fs::get_path solarish version.) - rust-lang#102445 (Add `is_empty()` method to `core::ffi::CStr`.) - rust-lang#102612 (Migrate `codegen_ssa` to diagnostics structs - [Part 1]) - rust-lang#102685 (Interpret EH actions properly) - rust-lang#102869 (Add basename and dirname aliases) - rust-lang#102889 (rustc_hir: Less error-prone methods for accessing `PartialRes` resolution) - rust-lang#102893 (Fix ICE rust-lang#102878) - rust-lang#102912 (:arrow_up: rust-analyzer) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
…-diagnostics-structs, r=davidtwco Migrate `codegen_ssa` to diagnostics structs - [Part 1] Initial migration of `codegen_ssa`. Going to split this crate migration in at least two PRs in order to avoid a huge PR and to quick off some questions around: 1. Translating messages from "external" crates. 2. Interfacing with OS messages. 3. Adding UI tests while migrating diagnostics. _See comments below._
…iaskrgr Rollup of 11 pull requests Successful merges: - rust-lang#100387 (Check uniqueness of impl items by trait item when applicable.) - rust-lang#101727 (Stabilize map_first_last) - rust-lang#101774 (Warn about safety of `fetch_update`) - rust-lang#102227 (fs::get_path solarish version.) - rust-lang#102445 (Add `is_empty()` method to `core::ffi::CStr`.) - rust-lang#102612 (Migrate `codegen_ssa` to diagnostics structs - [Part 1]) - rust-lang#102685 (Interpret EH actions properly) - rust-lang#102869 (Add basename and dirname aliases) - rust-lang#102889 (rustc_hir: Less error-prone methods for accessing `PartialRes` resolution) - rust-lang#102893 (Fix ICE rust-lang#102878) - rust-lang#102912 (:arrow_up: rust-analyzer) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
…ftl, r=oli-obk 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 rust-lang#102612 (comment), 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 rust-lang#100717
…l, r=oli-obk 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 rust-lang#102612 (comment), 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 rust-lang#100717
Initial migration of
codegen_ssa
. Going to split this crate migration in at least two PRs in order to avoid a huge PR and to quick off some questions around:See comments below.