Remove diagnostic translation infrastructure

[davidtwco]

Proposal

Since its initial implementation, the diagnostic translation effort (rust-lang/rust#100717) has stalled. Translatable diagnostic structs are partially used throughout the compiler but there are no translations for any of the diagnostics and it is unclear how translatable the messages ported to Fluent will be in practice (i.e. depending on how interpolation is used, it might not be possible to write a translated version of the diagnostic). Unfortunately, this infrastructure has significantly reduced the ergonomics of working on the compiler and there is no clear path forward to resolving those issues.

If we can find a way to do diagnostic translation in future, then we should definitely consider it, and this MCP should not be taken as an argument against any future efforts in this area. However, the current infrastructure has significant downsides and nobody willing to push it forward and make improvements, so it should be removed.

See previously:

• #i18n > #100717 diag translation @ 💬
• Const-eval InterpError: error enum variants vs throw_ub_custom! rust#112618
• We have quite different APIs for emitting a lint vs a hard error rust#121077

Mentors or Reviewers

If you have a reviewer or mentor in mind for this work, mention them here. You can put your own name here if you are planning to mentor the work.

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
• Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Caution

Concerns (1 active)

• people-like-structs

Managed by @rustbot—see help for details.

[rustbot]

Important

This issue is not meant to be used for technical discussion. There is a Zulip stream for that.
Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections can formally be registered here by adding a comment.

@rustbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rustbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler

[fee1-dead]

@rustbot concern people-like-structs

Probably needs consensus on what we do with struct based diagnostics - do we remove them wholesale? Keep when not causing too much maintainability churn? Or some other way

[estebank]

It might be possible to make the annotations that currently point at fluent slugs into formatting strings, so that you can still have

#[derive(Diagnostic)]
#[diag("parenthesized type parameters may only be used with a `Fn` trait", code = E0214)]
pub(crate) struct GenericTypeWithParentheses {
    #[primary_span]
    #[label("only `Fn` traits may use parentheses")]
    pub span: Span,
    #[subdiagnostic]
    pub sub: Option<UseAngleBrackets>,
}

The problem I see is that if we keep this support, then it doesn't really allow us to remove much baggage, does it?

(I am sad of seeing this go, but understand the reasoning.)