Diagnostic Internals: Arguments, Loading and Emitters

`DiagMessage` (using `DiagMessage::with_subdiagnostic_message`) to be emitted (an attribute name on its own is meaningless without a corresponding message identifier, which is what `DiagMessage` provides). Both `DiagMessage` and `SubdiagMessage` implement `Into` for any type that can be converted into a string, and converts these into non-translatable diagnostics - this keeps all existing diagnostic calls working. ### Arguments Additional context for Fluent messages which are interpolated into message contents needs to be provided to translatable diagnostics. Diagnostics have a `set_arg` function that can be used to provide this additional context to a diagnostic. Arguments have both a name (e.g. "what" in the earlier example) and a value. Argument values are represented using the `DiagArgValue` type, which is just a string or a number. rustc types can implement `IntoDiagArg` with conversion into a string or a number, and common types like `Ty<'tcx>` already have such implementations. `set_arg` calls are handled transparently by diagnostic derives but need to be added manually when using diagnostic builder APIs. ### Loading rustc makes a distinction between the "fallback bundle" for `en-US` that is used by default and when another locale is missing a message; and the primary fluent bundle which is requested by the user. Diagnostic emitters implement the `Emitter` trait which has two functions for accessing the fallback and primary fluent bundles (`fallback_fluent_bundle` and `fluent_bundle` respectively). `Emitter` also has member functions with default implementations for performing translation of a `DiagMessage` using the results of `fallback_fluent_bundle` and `fluent_bundle`. All of the emitters in rustc load the fallback Fluent bundle lazily, only reading Fluent resources and parsing them when an error message is first being translated (for performance reasons - it doesn't make sense to do this if no error is being emitted). `rustc_error_messages::fallback_fluent_bundle` returns a `std::lazy::Lazy<FluentBundle>` which is provided to emitters and evaluated in the first call to `Emitter::fallback_fluent_bundle`. The primary Fluent bundle (for the user's desired locale) is expected to be returned by `Emitter::fluent_bundle`. This bundle is used preferentially when translating messages, the fallback bundle is only used if the primary bundle is missing a message or not provided. There are no locale bundles distributed with the compiler, but mechanisms are implemented for loading them. - `-Ztranslate-additional-ftl` can be used to load a specific resource as the primary bundle for testing purposes. - `-Ztranslate-lang` can be provided a language identifier (something like `en-US`) and will load any Fluent resources found in `$sysroot/share/locale/$locale/` directory (both the user provided sysroot and any sysroot candidates). Primary bundles are not currently loaded lazily and if requested will be loaded at the start of compilation regardless of whether an error occurs. Lazily loading primary bundles is possible if it can be assumed that loading a bundle won't fail. Bundle loading can fail if a requested locale is missing, Fluent files are malformed, or a message is duplicated in multiple resources.

This section discusses how `set_arg` calls are handled in diagnostics and explains rustc's distinction between the 'fallback bundle' (en-US) and the primary fluent bundle requested by the user. Diagnostic emitters implement the `Emitter` trait, which provides functions for accessing both bundles. The fallback bundle is loaded lazily, while the primary bundle is loaded at the start of compilation, with mechanisms available to load resources for testing or specific locales. Primary bundles are not currently loaded lazily and if requested will be loaded at the start of compilation regardless of whether an error occurs.