1
Fork 0
Commit graph

5 commits

Author SHA1 Message Date
David Wood
81cf2294b4 macros: support adding warnings to diags
Both diagnostic and subdiagnostic derives were missing the ability to
add warnings to diagnostics - this is made more difficult by the `warn`
attribute already existing, so this name being unavailable for the
derives to use. `#[warn_]` is used instead, which requires
special-casing so that `{span_,}warn` is called instead of
`{span_,}warn_`.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-07-15 16:13:49 +01:00
Michael Goulet
34d6f08f4d Use dashes instead of underscores in fluent names 2022-07-08 03:37:36 +00:00
David Wood
99bc979403 macros: use typed identifiers in diag derive
Using typed identifiers instead of strings with the Fluent identifier
enables the diagnostic derive to benefit from the compile-time
validation that comes with typed identifiers - use of a non-existent
Fluent identifier will not compile.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-06-24 09:08:25 +01:00
David Wood
f669b78ffc errors: simplify referring to fluent attributes
To render the message of a Fluent attribute, the identifier of the
Fluent message must be known. `DiagnosticMessage::FluentIdentifier`
contains both the message's identifier and optionally the identifier of
an attribute. Generated constants for each attribute would therefore
need to be named uniquely (amongst all error messages) or be able to
refer to only the attribute identifier which will be combined with a
message identifier later. In this commit, the latter strategy is
implemented as part of the `Diagnostic` type's functions for adding
subdiagnostics of various kinds.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-05-30 13:38:19 +01:00
David Wood
552eb3295a macros: introduce fluent_messages macro
Adds a new `fluent_messages` macro which performs compile-time
validation of the compiler's Fluent resources (i.e. that the resources
parse and don't multiply define the same messages) and generates
constants that make using those messages in diagnostics more ergonomic.

For example, given the following invocation of the macro..

```ignore (rust)
fluent_messages! {
    typeck => "./typeck.ftl",
}
```
..where `typeck.ftl` has the following contents..

```fluent
typeck-field-multiply-specified-in-initializer =
    field `{$ident}` specified more than once
    .label = used more than once
    .label-previous-use = first use of `{$ident}`
```
...then the macro parse the Fluent resource, emitting a diagnostic if it
fails to do so, and will generate the following code:

```ignore (rust)
pub static DEFAULT_LOCALE_RESOURCES: &'static [&'static str] = &[
    include_str!("./typeck.ftl"),
];

mod fluent_generated {
    mod typeck {
        pub const field_multiply_specified_in_initializer: DiagnosticMessage =
            DiagnosticMessage::fluent("typeck-field-multiply-specified-in-initializer");
        pub const field_multiply_specified_in_initializer_label_previous_use: DiagnosticMessage =
            DiagnosticMessage::fluent_attr(
                "typeck-field-multiply-specified-in-initializer",
                "previous-use-label"
            );
    }
}
```

When emitting a diagnostic, the generated constants can be used as
follows:

```ignore (rust)
let mut err = sess.struct_span_err(
    span,
    fluent::typeck::field_multiply_specified_in_initializer
);
err.span_default_label(span);
err.span_label(
    previous_use_span,
    fluent::typeck::field_multiply_specified_in_initializer_label_previous_use
);
err.emit();
```

Signed-off-by: David Wood <david.wood@huawei.com>
2022-05-24 16:48:17 +01:00