Remove the fluent files

This MCP proposes:

• In code: Remove fluent files, while keeping struct diagnostics as a way of creating diagnostics.
• In mindset: Struct diagnostics are still the preferred and recommended way to do diagnostics. However, authors may choose to not use them if they are insufficient for the task, but this choice should be properly justified.

Edit 15-01-2026: To clarify, after this MCP, we will keep using fluent in the background for the formatting strings. Replacing fluent completely will be proposed in a future MCP, after we have a clear picture of what to replace it with. Since having fluent in the background is a logical implementation step anyways, this does not add much inefficiency.

For example, the following struct diagnostic as defined currently:

#[derive(Diagnostic)]
#[diag(attr_parsing_invalid_target)]
#[help]
pub(crate) struct InvalidTarget {
    #[primary_span]
    #[suggestion(code = "", applicability = "machine-applicable", style = "tool-only")]
    pub span: Span,
    pub name: AttrPath,
    pub target: &'static str,
    pub applied: DiagArgValue,
}

attr_parsing_invalid_target = `#[{$name}]` attribute cannot be used on {$target}
    .help = `#[{$name}]` can be applied to {$applied}
    .suggestion = remove the attribute

After this change, would become something like this

#[derive(Diagnostic)]
#[diag("`#[{name}]` attribute cannot be used on {target}")]
#[help("`#[{name}]` can be applied to {applied}")]
pub(crate) struct InvalidTarget {
    #[primary_span]
    #[suggestion("remove the attribute", code = "", applicability = "machine-applicable", style = "tool-only")]
    pub span: Span,
    pub name: AttrPath,
    pub target: &'static str,
    pub applied: DiagArgValue,
}

I'm very open to discussing the exact syntax, but this seems like a reasonable start to me.

Why this change?

• The fluent files being decoupled from the rest of the diagnostics reduces the ergonomics of working on the compiler. This is the minimal change that fixes this problem.
• 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). There currently seems to be nobody willing to push the translation effort forwards to solve this challenge.
• This change can likely be done mostly automatically with some scripting, making the change relatively easy to implement

See previously:

• Remove diagnostic translation infrastructure #924, this MCP succeeds this MCP by changing it to keep the struct diagnostics
• #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

cc @davidtwco

Mentors or Reviewers

I (@JonathanBrouwer) am willing to do the work necessary to make this change.
I have not asked around for anyone willing to review these changes yet. I'm planning on making the change in a lot of small PRs, to keep this work reviewable, but it will likely be a lot of review work regardless.

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.