remove extraneous note on UnableToRunDsymutil diagnostic
#124414
Conversation
rustbot
added
S-waiting-on-review
I'm surprised this isn't caught actually - it should be a compiler error. We generate a constant for each Fluent message and attribute (basically just containing the Fluent slug), and then that's what we reference in the diagnostic derive. A missing The check that you've found is for checking if each Fluent message doesn't reference any fields on the diagnostic type that don't exist - so that's actually checking something different than this case, if I understand everything correctly. That doesn't work for subdiagnostics because the field being referenced by the Fluent message might be part of the parent diagnostic.
This isn't possible - extraneous messages in Fluent don't cause any issues. I think we do have checks for this for top-level messages, but I guess not for Fluent attributes. |
|
@bors r+ rollup |
bors
added
S-waiting-on-bors
remove extraneous note on `UnableToRunDsymutil` diagnostic If I understand [this FIXME](https://github.com/rust-lang/rust/blob/1367827eac3d813a261a4c444037af9736996daa/compiler/rustc_macros/src/diagnostics/diagnostic.rs#L205) correctly, it seems we don't yet validate subdiagnostics, so `#[note]` and co in the `#[derive(Diagnostic]` item could be out-of-sync with the fluent message, without causing compile errors. It was the case for `rustc_codegen_ssa::errors::UnableToRunDsymutil`, causing the ICE in rust-lang#124392. I've grepped and scripted my way through most of our diagnostics structs and fluent bundles and the above was the only such extraneous `#[note]`/`#[note(name)]`/`#[help]`/`#[warning]` I could find, so hopefully there aren't many others like it. I haven't checked if the opposite can happen, a `.note = ` in a fluent message that is lacking a corresponding `#[note]` on the struct and not causing an error, but maybe it's possible? r? `@davidtwco` fixes rust-lang#124392
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#124138 (Ignore LLVM ABI in dlltool tests since those targets don't use dlltool) - rust-lang#124414 (remove extraneous note on `UnableToRunDsymutil` diagnostic) - rust-lang#124579 (Align: add bytes_usize and bits_usize) - rust-lang#124622 (Cleanup: Rid the `rmake` test runners of `extern crate run_make_support;`) - rust-lang#124623 (shallow resolve in orphan check) - rust-lang#124624 (Use `tcx.types.unit` instead of `Ty::new_unit(tcx)`) - rust-lang#124627 (interpret: hide some reexports in rustdoc) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#124414 - lqd:subdiagnostics, r=davidtwco remove extraneous note on `UnableToRunDsymutil` diagnostic If I understand [this FIXME](https://github.com/rust-lang/rust/blob/1367827eac3d813a261a4c444037af9736996daa/compiler/rustc_macros/src/diagnostics/diagnostic.rs#L205) correctly, it seems we don't yet validate subdiagnostics, so `#[note]` and co in the `#[derive(Diagnostic]` item could be out-of-sync with the fluent message, without causing compile errors. It was the case for `rustc_codegen_ssa::errors::UnableToRunDsymutil`, causing the ICE in rust-lang#124392. I've grepped and scripted my way through most of our diagnostics structs and fluent bundles and the above was the only such extraneous `#[note]`/`#[note(name)]`/`#[help]`/`#[warning]` I could find, so hopefully there aren't many others like it. I haven't checked if the opposite can happen, a `.note = ` in a fluent message that is lacking a corresponding `#[note]` on the struct and not causing an error, but maybe it's possible? r? ``@davidtwco`` fixes rust-lang#124392
If I understand this FIXME correctly, it seems we don't yet validate subdiagnostics, so
#[note]and co in the#[derive(Diagnostic]item could be out-of-sync with the fluent message, without causing compile errors.It was the case for
rustc_codegen_ssa::errors::UnableToRunDsymutil, causing the ICE in #124392.I've grepped and scripted my way through most of our diagnostics structs and fluent bundles and the above was the only such extraneous
#[note]/#[note(name)]/#[help]/#[warning]I could find, so hopefully there aren't many others like it.I haven't checked if the opposite can happen, a
.note =in a fluent message that is lacking a corresponding#[note]on the struct and not causing an error, but maybe it's possible?r? @davidtwco
fixes #124392