-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate codegen_ssa
to diagnostics structs - [Part 1]
#102612
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.