Migrate codegen_ssa to diagnostics structs - [Part 1]#102612
Merged
bors merged 11 commits intorust-lang:masterfrom Oct 11, 2022
Merged
Migrate codegen_ssa to diagnostics structs - [Part 1]#102612bors merged 11 commits intorust-lang:masterfrom
codegen_ssa to diagnostics structs - [Part 1]#102612bors merged 11 commits intorust-lang:masterfrom
Conversation
rustbot
added
A-translation
Contributor
|
r? @eholk (rust-highfive has picked a reviewer for you, use r? to override) |
Collaborator
|
cc @davidtwco, @compiler-errors, @JohnTitor, @estebank, @TaKO8Ki |
rust-highfive
added
the
S-waiting-on-review
JhonnyBillM
commented
Oct 3, 2022
JhonnyBillM
commented
Oct 3, 2022
JhonnyBillM
commented
Oct 3, 2022
JhonnyBillM
changed the title
codegen_ssa to diagnostics structs _[Part 1]_codegen_ssa to diagnostics structs - [Part 1]
davidtwco
requested changes
Oct 3, 2022
Member
davidtwco
left a comment
davidtwco
left a comment
There was a problem hiding this comment.
This is a great start, thanks!
eholk
approved these changes
Oct 3, 2022
Contributor
|
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 |
JhonnyBillM
force-pushed
the
migrate-codegen-ssa-to-diagnostics-structs
branch
from
8d94cda to
954a62f
Compare
This comment was marked as resolved.
This comment was marked as resolved.
JhonnyBillM
force-pushed
the
migrate-codegen-ssa-to-diagnostics-structs
branch
from
7d5f50f to
f69f1b0
Compare
JhonnyBillM
commented
Oct 4, 2022
davidtwco
reviewed
Oct 5, 2022
JhonnyBillM
force-pushed
the
migrate-codegen-ssa-to-diagnostics-structs
branch
from
f69f1b0 to
41ab94c
Compare
davidtwco
approved these changes
Oct 6, 2022
Member
|
@bors r+ |
Collaborator
|
📌 Commit 41ab94cb00f0e08590660260d20d4ba534042a88 has been approved by It is now in the queue for this repository. |
bors
added
S-waiting-on-bors
This comment was marked as resolved.
This comment was marked as resolved.
bors
removed
the
S-waiting-on-bors
rustbot
added
S-waiting-on-review
Member
|
@bors r+ |
Collaborator
bors
added
S-waiting-on-bors
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Oct 11, 2022
…-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._
Dylan-DPC
added a commit
to Dylan-DPC/rust
that referenced
this pull request
Oct 11, 2022
…-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._
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Oct 11, 2022
…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
2 tasks
Aaron1011
pushed a commit
to Aaron1011/rust
that referenced
this pull request
Jan 6, 2023
…-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._
Aaron1011
pushed a commit
to Aaron1011/rust
that referenced
this pull request
Jan 6, 2023
…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
compiler-errors
added a commit
to compiler-errors/rust
that referenced
this pull request
Feb 21, 2023
…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
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 22, 2023
…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
christian-schilling
pushed a commit
to christian-schilling/rustc_codegen_cranelift
that referenced
this pull request
Jan 27, 2026
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/rust#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 #100717
christian-schilling
pushed a commit
to christian-schilling/rustc_codegen_cranelift
that referenced
this pull request
Jan 27, 2026
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/rust#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 #100717
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.