Skip to content

Commit

Permalink
Rollup merge of rust-lang#98428 - davidtwco:translation-derive-typed-…
Browse files Browse the repository at this point in the history
…identifiers, r=oli-obk

macros: use typed identifiers in diag and subdiag derive

Using typed identifiers instead of strings with the Fluent identifiers in the diagnostic and subdiagnostic derives - this enables the diagnostic derive to benefit from the compile-time validation that comes with typed identifiers, namely that use of a non-existent Fluent identifier will not compile.

r? ``@oli-obk``
  • Loading branch information
Dylan-DPC committed Jun 26, 2022
2 parents 6144c43 + dc90d1d commit d50d461
Show file tree
Hide file tree
Showing 15 changed files with 971 additions and 669 deletions.
4 changes: 2 additions & 2 deletions compiler/rustc_builtin_macros/src/cfg.rs
Original file line number Diff line number Diff line change
Expand Up @@ -36,15 +36,15 @@ pub fn expand_cfg(
}

#[derive(SessionDiagnostic)]
#[error(slug = "builtin-macros-requires-cfg-pattern")]
#[error(builtin_macros::requires_cfg_pattern)]
struct RequiresCfgPattern {
#[primary_span]
#[label]
span: Span,
}

#[derive(SessionDiagnostic)]
#[error(slug = "builtin-macros-expected-one-cfg-pattern")]
#[error(builtin_macros::expected_one_cfg_pattern)]
struct OneCfgPattern {
#[primary_span]
span: Span,
Expand Down
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
builtin-macros-requires-cfg-pattern =
builtin_macros-requires-cfg-pattern =
macro requires a cfg-pattern as an argument
.label = cfg-pattern required
builtin-macros-expected-one-cfg-pattern = expected 1 cfg-pattern
builtin_macros-expected-one-cfg-pattern = expected 1 cfg-pattern
38 changes: 21 additions & 17 deletions compiler/rustc_error_messages/src/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -258,18 +258,6 @@ pub enum SubdiagnosticMessage {
FluentAttr(FluentId),
}

impl SubdiagnosticMessage {
/// Create a `SubdiagnosticMessage` for the provided Fluent attribute.
pub fn attr(id: impl Into<FluentId>) -> Self {
SubdiagnosticMessage::FluentAttr(id.into())
}

/// Create a `SubdiagnosticMessage` for the provided Fluent identifier.
pub fn message(id: impl Into<FluentId>) -> Self {
SubdiagnosticMessage::FluentIdentifier(id.into())
}
}

/// `From` impl that enables existing diagnostic calls to functions which now take
/// `impl Into<SubdiagnosticMessage>` to continue to work as before.
impl<S: Into<String>> From<S> for SubdiagnosticMessage {
Expand Down Expand Up @@ -332,11 +320,6 @@ impl DiagnosticMessage {
_ => panic!("expected non-translatable diagnostic message"),
}
}

/// Create a `DiagnosticMessage` for the provided Fluent identifier.
pub fn new(id: impl Into<FluentId>) -> Self {
DiagnosticMessage::FluentIdentifier(id.into(), None)
}
}

/// `From` impl that enables existing diagnostic calls to functions which now take
Expand All @@ -347,6 +330,27 @@ impl<S: Into<String>> From<S> for DiagnosticMessage {
}
}

/// Translating *into* a subdiagnostic message from a diagnostic message is a little strange - but
/// the subdiagnostic functions (e.g. `span_label`) take a `SubdiagnosticMessage` and the
/// subdiagnostic derive refers to typed identifiers that are `DiagnosticMessage`s, so need to be
/// able to convert between these, as much as they'll be converted back into `DiagnosticMessage`
/// using `with_subdiagnostic_message` eventually. Don't use this other than for the derive.
impl Into<SubdiagnosticMessage> for DiagnosticMessage {
fn into(self) -> SubdiagnosticMessage {
match self {
DiagnosticMessage::Str(s) => SubdiagnosticMessage::Str(s),
DiagnosticMessage::FluentIdentifier(id, None) => {
SubdiagnosticMessage::FluentIdentifier(id)
}
// There isn't really a sensible behaviour for this because it loses information but
// this is the most sensible of the behaviours.
DiagnosticMessage::FluentIdentifier(_, Some(attr)) => {
SubdiagnosticMessage::FluentAttr(attr)
}
}
}
}

/// A span together with some additional data.
#[derive(Clone, Debug)]
pub struct SpanLabel {
Expand Down
Loading

0 comments on commit d50d461

Please sign in to comment.