-
Couldn't load subscription status.
- Fork 13.9k
errors: only eagerly translate subdiagnostics #121085
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
Conversation
|
Some changes might have occurred in exhaustiveness checking cc @Nadrieril Some changes occurred in compiler/rustc_codegen_gcc
cc @davidtwco, @compiler-errors, @TaKO8Ki The Miri subtree was changed cc @rust-lang/miri Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
This comment has been minimized.
This comment has been minimized.
2bd6241 to
f6cd442
Compare
This comment has been minimized.
This comment has been minimized.
f6cd442 to
7721242
Compare
|
Some changes occurred in src/tools/rustfmt cc @rust-lang/rustfmt
|
| fn decorate(mut self, dcx: &DiagCtxtInner) -> Diagnostic { | ||
| // FIXME: Cannot use `Diagnostic::subdiagnostic` which takes `DiagCtxt`, but it | ||
| // just uses `DiagCtxtInner` functions. | ||
| let subdiag_with = |diag: &mut Diagnostic, msg| { |
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.
Can you pull this closure out further and use it for the FIXME cases above?
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.
I'm not sure I understand what that would look like.
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.
If you pulled this closure out into a method on DiagCtxtInner, then you could use it in flush_delayed, where the FIXME comment is.
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.
It's a little tricky to do this. I can't make the closure a method because the signature wouldn't match (add_to_diagnostic_with doesn't expect a &Self), it can't be a function which doesn't take self because it needs the reference to DiagCtxtInner (which we capture currently), and returning a closure that does match from this function is tricky because the closure captures the lifetime. I'm hoping to be able to remove the closure here in a follow-up anyway.
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.
ok
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 seems mostly good, but it feels like it's missing a couple of things.
- Should
DiagnosticMessage::EagerandSubdiagnosticMessage::Eagerbe renamed? Also, the comments on those variants talk about eager vs. non-eager translation, and should be updated. - Can
AddToDiagnosticbe simplified? Isadd_to_diagnosticuseful any more? Maybeadd_to_diagnostic_withcan be removed andadd_to_diagnosticalways do what thatsubdiag_withclosure does (though that requires adcx).
7721242 to
2097ec3
Compare
|
|
Fixed!
I intend to do this as a follow-up, this is just the first part of larger changes I'm making to move Fluent messages into the structs and out of the ftl files, to merge |
|
AFAICT you've updated |
Subdiagnostics don't need to be lazily translated, they can always be eagerly translated. Eager translation is slightly more complex as we need to have a `DiagCtxt` available to perform the translation, which involves slightly more threading of that context. This slight increase in complexity should enable later simplifications - like passing `DiagCtxt` into `AddToDiagnostic` and moving Fluent messages into the diagnostic structs rather than having them in separate files (working on that was what led to this change). Signed-off-by: David Wood <david@davidtw.co>
2097ec3 to
b80fc5d
Compare
🤦 fixed! |
|
@bors r+ |
…, r=nnethercote errors: only eagerly translate subdiagnostics Subdiagnostics don't need to be lazily translated, they can always be eagerly translated. Eager translation is slightly more complex as we need to have a `DiagCtxt` available to perform the translation, which involves slightly more threading of that context. This slight increase in complexity should enable later simplifications - like passing `DiagCtxt` into `AddToDiagnostic` and moving Fluent messages into the diagnostic structs rather than having them in separate files (working on that was what led to this change). r? `@nnethercote`
…, r=nnethercote errors: only eagerly translate subdiagnostics Subdiagnostics don't need to be lazily translated, they can always be eagerly translated. Eager translation is slightly more complex as we need to have a `DiagCtxt` available to perform the translation, which involves slightly more threading of that context. This slight increase in complexity should enable later simplifications - like passing `DiagCtxt` into `AddToDiagnostic` and moving Fluent messages into the diagnostic structs rather than having them in separate files (working on that was what led to this change). r? `@nnethercote`
…, r=nnethercote errors: only eagerly translate subdiagnostics Subdiagnostics don't need to be lazily translated, they can always be eagerly translated. Eager translation is slightly more complex as we need to have a `DiagCtxt` available to perform the translation, which involves slightly more threading of that context. This slight increase in complexity should enable later simplifications - like passing `DiagCtxt` into `AddToDiagnostic` and moving Fluent messages into the diagnostic structs rather than having them in separate files (working on that was what led to this change). r? ``@nnethercote``
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#120952 (Don't use mem::zeroed in vec::IntoIter) - rust-lang#121079 (distribute tool documentations and avoid file conflicts on `x install`) - rust-lang#121085 (errors: only eagerly translate subdiagnostics) - rust-lang#121091 (use build.rustc config and skip-stage0-validation flag) - rust-lang#121193 (Use fulfillment in next trait solver coherence) - rust-lang#121209 (Make `CodegenBackend::join_codegen` infallible.) - rust-lang#121210 (Fix `cfg(target_abi = "sim")` on `i386-apple-ios`) - rust-lang#121228 (create stamp file for clippy) r? `@ghost` `@rustbot` modify labels: rollup
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#120952 (Don't use mem::zeroed in vec::IntoIter) - rust-lang#121085 (errors: only eagerly translate subdiagnostics) - rust-lang#121091 (use build.rustc config and skip-stage0-validation flag) - rust-lang#121149 (Fix typo in VecDeque::handle_capacity_increase() doc comment.) - rust-lang#121193 (Use fulfillment in next trait solver coherence) - rust-lang#121209 (Make `CodegenBackend::join_codegen` infallible.) - rust-lang#121210 (Fix `cfg(target_abi = "sim")` on `i386-apple-ios`) - rust-lang#121228 (create stamp file for clippy) - rust-lang#121231 (remove a couple of redundant clones) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#121085 - davidtwco:always-eager-diagnostics, r=nnethercote errors: only eagerly translate subdiagnostics Subdiagnostics don't need to be lazily translated, they can always be eagerly translated. Eager translation is slightly more complex as we need to have a `DiagCtxt` available to perform the translation, which involves slightly more threading of that context. This slight increase in complexity should enable later simplifications - like passing `DiagCtxt` into `AddToDiagnostic` and moving Fluent messages into the diagnostic structs rather than having them in separate files (working on that was what led to this change). r? ```@nnethercote```
|
|
||
| // Override `translate_message` for the silent emitter because eager translation of | ||
| // subdiagnostics result in a call to this. | ||
| fn translate_message<'a>( | ||
| &'a self, | ||
| message: &'a rustc_errors::DiagnosticMessage, | ||
| _: &'a rustc_errors::translation::FluentArgs<'_>, | ||
| ) -> Result<Cow<'_, str>, rustc_errors::error::TranslateError<'_>> { | ||
| rustc_errors::emitter::silent_translate(message) | ||
| } |
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.
Haven't got confirmation from the user yet if they're using a recent nightly version of rustfmt, but we just got a report about the SilentEmitter in rust-lang/rustfmt#6082 and this PR is the only one I can think of that made changes recently. @davidtwco would you mind looking into this.
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.
@davidtwco @nnethercote I got confirmation from the user who reported the issue that this started happening after they installed the latest nightly. Also, they helped to provide this minimal input snippet, which I've also tested and can confirm that it causes a panic when running rustfmt +nightly-2024-02-18
macro_rules! test {
($T:ident, $b:lifetime) => {
Box<$T<$b>>
};
}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.
Yes, this PR is almost certainly the cause. I assume @davidtwco will look into it soon.
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.
I'm working on this in #121301.
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.
@davidtwco thank you for the help on this one 🙏🏼
…, r=nnethercote errors: only eagerly translate subdiagnostics Subdiagnostics don't need to be lazily translated, they can always be eagerly translated. Eager translation is slightly more complex as we need to have a `DiagCtxt` available to perform the translation, which involves slightly more threading of that context. This slight increase in complexity should enable later simplifications - like passing `DiagCtxt` into `AddToDiagnostic` and moving Fluent messages into the diagnostic structs rather than having them in separate files (working on that was what led to this change). r? ```@nnethercote```
…, r=nnethercote errors: only eagerly translate subdiagnostics Subdiagnostics don't need to be lazily translated, they can always be eagerly translated. Eager translation is slightly more complex as we need to have a `DiagCtxt` available to perform the translation, which involves slightly more threading of that context. This slight increase in complexity should enable later simplifications - like passing `DiagCtxt` into `AddToDiagnostic` and moving Fluent messages into the diagnostic structs rather than having them in separate files (working on that was what led to this change). r? ```@nnethercote```
Subdiagnostics don't need to be lazily translated, they can always be eagerly translated. Eager translation is slightly more complex as we need to have a
DiagCtxtavailable to perform the translation, which involves slightly more threading of that context.This slight increase in complexity should enable later simplifications - like passing
DiagCtxtintoAddToDiagnosticand moving Fluent messages into the diagnostic structs rather than having them in separate files (working on that was what led to this change).r? @nnethercote