Tracking Issue for rustc's translatable diagnostics infrastructure

[jieyouxu]

This is a tracking issue for rustc's translatable diagnostics infrastructure, which is related to #100717 but reflects the current status.

Current status

Unfortunately, we have found that the current implementation of diagnostic translation infrastructure causes significant friction for compiler contributors when trying to work on diagnostics, including but not limited to:

• Having to edit multiple files (fluent file, errors.rs and the emission site, etc.)
• The diagnostics derive DSL is quite complex and exhibits some quirks
• Fluent DSL also has its own quirks
• Sometimes not sufficiently flexible to accommodate diagnostic needs, e.g. see rustc_const_eval or other not-migrated examples.

Important

Based on these friction points, we want to downgrade the internal lints untranslatable_diagnostic/diagnostic_outside_of_impl requiring usage of current translatable diagnostic infra from deny to allow.

If someone wants to continue the translatable diagnostics effort, then they will need to come up with a better redesign that causes less friction for compiler contributors.

Related discussions

• Const-eval InterpError: error enum variants vs throw_ub_custom! #112618
• We have quite different APIs for emitting a lint vs a hard error #121077
• rustc build: Pretty bad error message when there is a syntax error in an flt file #137223

Implementation steps

Relaxing the current restrictions

• Downgrade untranslatable_diagnostic and diagnostic_outside_of_impl from deny to allow.
  • Downgrade untranslatable_diagnostic and diagnostic_outside_of_impl to allow #132182
• Update rustc-dev-guide to reflect current status of translatable diagnostics infrastructure.
  • Update current status of diagnostics translation infra rustc-dev-guide#2105

Come up with a redesign

Note: this is not currently being actively worked on AFAICT, please speak with wg-diagnostics and T-compiler if you wish to pursue this. See specifically https://rust-lang.zulipchat.com/#narrow/channel/336883-i18n/topic/.23100717.20diag.20translation/near/472701978.

• A redesign of the translatable diagnostics infra will need to address the needs of both compiler contributors and translation teams. In particular, it cannot cause significant burden or friction for compiler contributors.

Further steps are presently unclear.

Unresolved questions

• What do we do with the current diagnostic translation infrastructure?
  • It's a lot of work and churn to rip it out, as well.
• What about the Pontoon infrastructure?
• What about translation teams?

Implementation / experimentation history

This listing is moreso focused on diagnostic infra itself, not migration efforts. Please see the closed PRs for what concrete issues they have ran into.

• Raw fluent diagnostic structs #121334
• New attribute macros format for diagnostic structs without fluent slug #117867
• Make lint diagnostics responsible for providing their primary span #125208

More discussions

• https://rust-lang.zulipchat.com/#narrow/channel/336883-i18n/topic/.23100717.20diag.20translation/near/472701978
• New attribute macros format for diagnostic structs without fluent slug #117867 (comment)
• https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Localization.20infra.20interferes.20with.20grepping.20for.20error

---

cc @rust-lang/wg-diagnostics