Distributed Slices for more erganomic diagnostic translation

compiler
1

Currently, the translatable diagnostics effort is on hold due to causing a lot of friction for compiler contributors.

I think we should revisit the global registration idea to try to address this.

The main issue this attempts to address is all the boilerplate required for new diagnostics. Currently, when adding a new diagnostic, at least 3 sites need to be updated:

  1. the emission site
  2. the definition of the diagnostic
  3. the messages.ftl file

Ideally, we could write a procedural macro that could handle all of this in one easy step, but we can't do that, because the messages all need to be collected into a fluent bundle, and that means they either have to all appear together, or there needs to be a list of all the places they appear, both of which mean updating two locations.

If we had some sort of distributed slice mechanism, we could have the distributed slice defined by the fluent_messages! macro, and then we could add a new macro, fluent_diag![1], that would automatically:

  • make a diagnostic name and struct name based off of the passed identifiers[2]
  • define a struct using derive(Diagnostic), using the fields passed
  • append a message to the distributed list based on the diagnostic name and the passed message
  • construct and return this struct based on the passed values
fn emit_some_lint(cx: &LateContext, span: Span, ident: Symbol) {
  let diag = fluent_diag!(some_lint, "something is wrong with $ident", ident: &str = ident.as_str());
  cx.emit_span_lint(SOME_LINT, span, diag);
}

  1. name subject to bikeshedding ↩︎

  2. the diagnostic name would also use the crate name as a prefix ↩︎

8 Likes
2

In order to not block one major feature on another, we could borrow an idea from gettext and have a program (run by build.rs or x, whichever is more convenient) that would extract the arguments of fluent_diag! directly from the source code and compile them into the messages.ftl file, which would then be both handed off to the translators and fed back into the build.

If we ever do get distributed slices, that program would still need to exist (because we still need to give the translators the messages.ftl file) but it wouldn't need to feed back into the build and maybe it wouldn't need to parse the source anymore either.

2 Likes