Update slug style to use _ instead of - (#1426)

src/diagnostics/diagnostic-structs.md

@@ -23,7 +23,7 @@ pub struct FieldAlreadyDeclared {
     #[primary_span]
     #[label]
     pub span: Span,
-    #[label = "previous-decl-label"]
+    #[label(typeck::previous_decl_label)]
     pub prev_span: Span,
 }
 ```
@@ -49,13 +49,13 @@ In our example, the Fluent message for the "field already declared" diagnostic
 looks like this:
 
 ```fluent
-typeck-field-already-declared =
+typeck_field_already_declared =
     field `{$field_name}` is already declared
     .label = field already declared
-    .previous-decl-label = `{$field_name}` first declared here
+    .previous_decl_label = `{$field_name}` first declared here
 ```
 
-`typeck-field-already-declared` is the slug from our example and is followed
+`typeck_field_already_declared` is the slug from our example and is followed
 by the diagnostic message.
 
 Every field of the `SessionDiagnostic` which does not have an annotation is
@@ -75,10 +75,10 @@ type `Span`. Applying any of these attributes will create the corresponding
 subdiagnostic with that `Span`. These attributes will look for their
 diagnostic message in a Fluent attribute attached to the primary Fluent
 message. In our example, `#[label]` will look for
-`typeck-field-already-declared.label` (which has the message "field already
+`typeck_field_already_declared.label` (which has the message "field already
 declared"). If there is more than one subdiagnostic of the same type, then
 these attributes can also take a value that is the attribute name to look for
-(e.g. `previous-decl-label` in our example).
+(e.g. `previous_decl_label` in our example).
 
 Other types have special behavior when used in a `SessionDiagnostic` derive:
 
@@ -115,18 +115,15 @@ In the end, the `SessionDiagnostic` derive will generate an implementation of
 ```rust,ignore
 impl SessionDiagnostic for FieldAlreadyDeclared {
     fn into_diagnostic(self, sess: &'_ rustc_session::Session) -> DiagnosticBuilder<'_> {
-        let mut diag = sess.struct_err_with_code(
+        let mut diag = sess.struct_err(rustc_errors::fluent::typeck::field_already_declared);
-            rustc_errors::DiagnosticMessage::fluent("typeck-field-already-declared"),
-            rustc_errors::DiagnosticId::Error("E0124")
-        );
         diag.set_span(self.span);
         diag.span_label(
             self.span,
-            rustc_errors::DiagnosticMessage::fluent_attr("typeck-field-already-declared", "label")
+            rustc_errors::fluent::typeck::label
         );
         diag.span_label(
             self.prev_span,
-            rustc_errors::DiagnosticMessage::fluent_attr("typeck-field-already-declared", "previous-decl-label")
+            rustc_errors::fluent::typeck::previous_decl_label
         );
         diag
     }
@@ -258,9 +255,9 @@ In our example, the Fluent message for the "expected return type" label
 looks like this:
 
 ```fluent
-typeck-expected-default-return-type = expected `()` because of default return type
+typeck_expected_default_return_type = expected `()` because of default return type
 
-typeck-expected-return-type = expected `{$expected}` because of return type
+typeck_expected_return_type = expected `{$expected}` because of return type
 ```
 
 Using the `#[primary_span]` attribute on a field (with type `Span`) will denote
@@ -304,11 +301,11 @@ impl<'tcx> AddToDiagnostic for ExpectedReturnTypeLabel<'tcx> {
         use rustc_errors::{Applicability, IntoDiagnosticArg};
         match self {
             ExpectedReturnTypeLabel::Unit { span } => {
-                diag.span_label(span, DiagnosticMessage::fluent("typeck-expected-default-return-type"))
+                diag.span_label(span, rustc_errors::fluent::typeck::expected_default_return_type)
             }
             ExpectedReturnTypeLabel::Other { span, expected } => {
                 diag.set_arg("expected", expected);
-                diag.span_label(span, DiagnosticMessage::fluent("typeck-expected-return-type"))
+                diag.span_label(span, rustc_errors::fluent::typeck::expected_return_type)
             }
 
         }

src/diagnostics/translation.md

@@ -32,23 +32,23 @@ Diagnostic messages are defined in Fluent resources. A combined set of Fluent
 resources for a given locale (e.g. `en-US`) is known as Fluent bundle.
 
 ```fluent
-typeck-address-of-temporary-taken = cannot take address of a temporary
+typeck_address_of_temporary_taken = cannot take address of a temporary
 ```
 
-In the above example, `typeck-address-of-temporary-taken` is the identifier for
+In the above example, `typeck_address_of_temporary_taken` is the identifier for
 a Fluent message and corresponds to the diagnostic message in English. Other
 Fluent resources can be written which would correspond to a message in another
 language. Each diagnostic therefore has at least one Fluent message.
 
 ```fluent
-typeck-address-of-temporary-taken = cannot take address of a temporary
+typeck_address_of_temporary_taken = cannot take address of a temporary
     .label = temporary value
 ```
 
 By convention, diagnostic messages for subdiagnostics are specified as
 "attributes" on Fluent messages (additional related messages, denoted by the
 `.<attribute-name>` syntax). In the above example, `label` is an attribute of
-`typeck-address-of-temporary-taken` which corresponds to the message for the
+`typeck_address_of_temporary_taken` which corresponds to the message for the
 label added to this diagnostic.
 
 Diagnostic messages often interpolate additional context into the message shown
@@ -56,7 +56,7 @@ to the user, such as the name of a type or of a variable. Additional context to
 Fluent messages is provided as an "argument" to the diagnostic.
 
 ```fluent
-typeck-struct-expr-non-exhaustive =
+typeck_struct_expr_non_exhaustive =
     cannot create non-exhaustive {$what} using struct expression
 ```
 
@@ -67,6 +67,13 @@ discussed in detail later).
 You can consult the [Fluent] documentation for other usage examples of Fluent
 and its syntax.
 
+### Guideline for message naming
+Usually, fluent uses `-` for separating words inside a message name. However,
+`_` is accepted by fluent as well. As `_` fits Rust's use cases better, due to
+the identifiers on the Rust side using `_` as well, inside rustc, `-` is not
+allowed for separating words, and instead `_` is recommended. The only exception
+is for leading `-`s, for message names like `-passes_see_issue`.
+
 ### Guidelines for writing translatable messages
 For a message to be translatable into different languages, all of the
 information required by any language must be provided to the diagnostic as an
@@ -106,10 +113,10 @@ fluent_messages! {
 For example, given the following Fluent...
 
 ```fluent
-typeck-field-multiply-specified-in-initializer =
+typeck_field_multiply_specified_in_initializer =
     field `{$ident}` specified more than once
     .label = used more than once
-    .label-previous-use = first use of `{$ident}`
+    .label_previous_use = first use of `{$ident}`
 ```
 
 ...then the `fluent_messages` macro will generate:
@@ -122,11 +129,11 @@ pub static DEFAULT_LOCALE_RESOURCES: &'static [&'static str] = &[
 mod fluent_generated {
     mod typeck {
         pub const field_multiply_specified_in_initializer: DiagnosticMessage =
-            DiagnosticMessage::new("typeck-field-multiply-specified-in-initializer");
+            DiagnosticMessage::new("typeck_field_multiply_specified_in_initializer");
         pub const label: SubdiagnosticMessage =
             SubdiagnosticMessage::attr("label");
         pub const label_previous_use: SubdiagnosticMessage =
-            SubdiagnosticMessage::attr("previous-use-label");
+            SubdiagnosticMessage::attr("previous_use_label");
     }
 }
 ```