Use translatable diagnostics in rustc_const_eval

[fee1-dead]

This PR:

• adds a no_span parameter to note / help attributes when using Subdiagnostic to allow adding notes/helps without using a span
• has minor tweaks and changes to error messages

[rustbot]

r? @oli-obk

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

rustc_macros::diagnostics was changed

cc @davidtwco, @compiler-errors, @JohnTitor, @TaKO8Ki

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

This PR changes MIR

cc @oli-obk, @RalfJung, @JakobDegen, @davidtwco, @celinval, @vakaras

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

[rustbot]

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

[RalfJung]

We have plans to change the error rendering for const-eval and Miri errors quite a bit, see rust-lang/miri#2200. I have no idea how that interacts with these translation changes, does it make them harder or easier? I expect harder because now there is another huge new subsystem one has to learn to even being doing such a change.

[RalfJung]

If this has a dedicated message now, why should it still use the Custom variant?

Or conversely, if Custom variants are now 'typed' like this, then why do we need the other variants at all?

Also, for Miri we can still use arbitrary strings here, right?

[fee1-dead]

You are right that this doesn't need to be Custom, but I think this should be done as followup work since this PR is already enormous.

[RalfJung]

I'm fine with leaving FIXMEs, I was just trying to understand why the code looks the way it does. If anything I feel it'd make sense to move more messages to Custom than the other way around, but I might be missing some parts of the trade-off here.

[RalfJung]

Are all these types here auto-generated or do they need to be manually synced with the .flt file (in terms of field/variable names etc)?

[fee1-dead]

Manually synced.

[RalfJung]

Uff, that's suboptimal, and so easy to get wrong. I thought "there is no variable named foo" is an error you see at runtime in Python bot not Rust ;) . Are there plans to improve this? Currently it looks like translations introduce quite a bit of boilerplate and make the code significantly more fragile. I'm very happy the core interpreter rarely changes these days, or else I would be worried about its future development being impacted.

[fee1-dead]

Yeah it's definitely increasing the work required to add a variant to InterpError.

I think it would be nice if there is a DSL that generated both fluent resources and the Rust types that derived Diagnostic and Subdiagnostic, but I'm not sure if that's the plan.

cc @rust-lang/wg-diagnostics any thoughts on this?

[clubby789]

I have a PR to validate variables used open (#111269) but it unfortunately doesn't work with subdiagnostics

[RalfJung]

fluent is already doing some form of code generation (right? I saw some use statements that look like this), so I was hoping a fluent line like

middle_uninit_unsized_local =
    unsized local is used while uninitialized {$variable}

could auto-generate a corresponding Rust struct with a field for the variable. Then we don't need a separate pass to check things, we get the check just directly as part of compilation.

I assume there are good reasons for why fluent works the way it does, but it sure does not feel very "rust-y" to me.

[fee1-dead]

does it make them harder or easier? I expect harder because now there is another huge new subsystem one has to learn to even being doing such a change.

I think I could do it in this PR by adding an enum that prints brief "title"s for errors. This PR also makes it impossible to use InterpError as the "title" of an error since the current change makes it so that it can only do span_labels or attach messages to an existing diagnostic.

[RalfJung]

does it make them harder or easier? I expect harder because now there is another huge new subsystem one has to learn to even being doing such a change.

I think I could do it in this PR by adding an enum that prints brief "title"s for errors. This PR also makes it impossible to use InterpError as the "title" of an error since the current change makes it so that it can only do span_labels or attach messages to an existing diagnostic.

Probably better to separate functional changes from major refactors like this.

However Miri currently relies quite a bit on the ability to put InterpError into the title...

[bors]

☔ The latest upstream changes (presumably #111680) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

rustc_error_messages was changed

cc @davidtwco, @compiler-errors, @JohnTitor, @TaKO8Ki

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[fee1-dead]

fixed ci error

@bors r=oli-obk,RalfJung

[bors]

📌 Commit b569845b920793b9797c2a704a24a11569e18d2a has been approved by oli-obk,RalfJung

It is now in the queue for this repository.

[bors]

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

1. git checkout rustc_const_eval-translatable (switch to your branch)
2. git fetch upstream master (retrieve the latest master)
3. git rebase upstream/master -p (rebase on top of it)
4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
5. git push self rustc_const_eval-translatable --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message

Auto-merging compiler/rustc_middle/src/mir/interpret/error.rs
CONFLICT (content): Merge conflict in compiler/rustc_middle/src/mir/interpret/error.rs
Auto-merging compiler/rustc_const_eval/src/interpret/eval_context.rs
Auto-merging compiler/rustc_const_eval/src/errors.rs
CONFLICT (content): Merge conflict in compiler/rustc_const_eval/src/errors.rs
Auto-merging compiler/rustc_const_eval/src/const_eval/machine.rs
Auto-merging compiler/rustc_const_eval/src/const_eval/eval_queries.rs
Auto-merging compiler/rustc_const_eval/messages.ftl
CONFLICT (content): Merge conflict in compiler/rustc_const_eval/messages.ftl
Automatic merge failed; fix conflicts and then commit the result.

[RalfJung]

@bors p=1 (bitrotty)

[fee1-dead]

rebased

@bors r=oli-obk,RalfJung

[bors]

📌 Commit f6c2bc5 has been approved by oli-obk,RalfJung

It is now in the queue for this repository.

[bors]

⌛ Testing commit f6c2bc5 with merge 33c3d10...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk,RalfJung
Pushing 33c3d10 to master...

[rust-timer]

Finished benchmarking commit (33c3d10): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.1%	[1.0%, 1.1%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 644.915s -> 644.751s (-0.03%)