Use `tidy` to sort crate attributes for all compiler crates.
We already do this for a number of crates, e.g. `rustc_middle`,
`rustc_span`, `rustc_metadata`, `rustc_span`, `rustc_errors`.
For the ones we don't, in many cases the attributes are a mess.
- There is no consistency about order of attribute kinds (e.g.
`allow`/`deny`/`feature`).
- Within attribute kind groups (e.g. the `feature` attributes),
sometimes the order is alphabetical, and sometimes there is no
particular order.
- Sometimes the attributes of a particular kind aren't even grouped
all together, e.g. there might be a `feature`, then an `allow`, then
another `feature`.
This commit extends the existing sorting to all compiler crates,
increasing consistency. If any new attribute line is added there is now
only one place it can go -- no need for arbitrary decisions.
Exceptions:
- `rustc_log`, `rustc_next_trait_solver` and `rustc_type_ir_macros`,
because they have no crate attributes.
- `rustc_codegen_gcc`, because it's quasi-external to rustc (e.g. it's
ignored in `rustfmt.toml`).
2024-06-12 13:49:36 +10:00
|
|
|
// tidy-alphabetical-start
|
|
|
|
#![allow(internal_features)]
|
|
|
|
#![allow(rustc::default_hash_types)]
|
2023-04-16 14:33:00 +02:00
|
|
|
#![doc(html_root_url = "https://doc.rust-lang.org/nightly/nightly-rustc/")]
|
2023-11-13 07:39:17 -05:00
|
|
|
#![doc(rust_logo)]
|
2023-04-16 14:33:00 +02:00
|
|
|
#![feature(proc_macro_diagnostic)]
|
|
|
|
#![feature(proc_macro_span)]
|
Use `tidy` to sort crate attributes for all compiler crates.
We already do this for a number of crates, e.g. `rustc_middle`,
`rustc_span`, `rustc_metadata`, `rustc_span`, `rustc_errors`.
For the ones we don't, in many cases the attributes are a mess.
- There is no consistency about order of attribute kinds (e.g.
`allow`/`deny`/`feature`).
- Within attribute kind groups (e.g. the `feature` attributes),
sometimes the order is alphabetical, and sometimes there is no
particular order.
- Sometimes the attributes of a particular kind aren't even grouped
all together, e.g. there might be a `feature`, then an `allow`, then
another `feature`.
This commit extends the existing sorting to all compiler crates,
increasing consistency. If any new attribute line is added there is now
only one place it can go -- no need for arbitrary decisions.
Exceptions:
- `rustc_log`, `rustc_next_trait_solver` and `rustc_type_ir_macros`,
because they have no crate attributes.
- `rustc_codegen_gcc`, because it's quasi-external to rustc (e.g. it's
ignored in `rustfmt.toml`).
2024-06-12 13:49:36 +10:00
|
|
|
#![feature(rustdoc_internals)]
|
2024-10-19 22:30:41 +08:00
|
|
|
#![feature(track_path)]
|
Use `tidy` to sort crate attributes for all compiler crates.
We already do this for a number of crates, e.g. `rustc_middle`,
`rustc_span`, `rustc_metadata`, `rustc_span`, `rustc_errors`.
For the ones we don't, in many cases the attributes are a mess.
- There is no consistency about order of attribute kinds (e.g.
`allow`/`deny`/`feature`).
- Within attribute kind groups (e.g. the `feature` attributes),
sometimes the order is alphabetical, and sometimes there is no
particular order.
- Sometimes the attributes of a particular kind aren't even grouped
all together, e.g. there might be a `feature`, then an `allow`, then
another `feature`.
This commit extends the existing sorting to all compiler crates,
increasing consistency. If any new attribute line is added there is now
only one place it can go -- no need for arbitrary decisions.
Exceptions:
- `rustc_log`, `rustc_next_trait_solver` and `rustc_type_ir_macros`,
because they have no crate attributes.
- `rustc_codegen_gcc`, because it's quasi-external to rustc (e.g. it's
ignored in `rustfmt.toml`).
2024-06-12 13:49:36 +10:00
|
|
|
// tidy-alphabetical-end
|
2023-04-16 14:33:00 +02:00
|
|
|
|
|
|
|
use proc_macro::TokenStream;
|
|
|
|
|
|
|
|
mod fluent;
|
|
|
|
|
|
|
|
/// Implements the `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.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_RESOURCE: &'static [&'static str] = include_str!("./typeck.ftl");
|
|
|
|
///
|
|
|
|
/// mod fluent_generated {
|
|
|
|
/// mod typeck {
|
2024-02-29 11:58:51 +11:00
|
|
|
/// pub const field_multiply_specified_in_initializer: DiagMessage =
|
|
|
|
/// DiagMessage::fluent("typeck_field_multiply_specified_in_initializer");
|
|
|
|
/// pub const field_multiply_specified_in_initializer_label_previous_use: DiagMessage =
|
|
|
|
/// DiagMessage::fluent_attr(
|
2023-04-16 14:33:00 +02:00
|
|
|
/// "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();
|
|
|
|
/// ```
|
2023-11-22 12:48:18 +11:00
|
|
|
///
|
|
|
|
/// Note: any crate using this macro must also have a dependency on
|
|
|
|
/// `rustc_errors`, because the generated code refers to things from that
|
|
|
|
/// crate.
|
2023-04-16 14:33:00 +02:00
|
|
|
#[proc_macro]
|
|
|
|
pub fn fluent_messages(input: TokenStream) -> TokenStream {
|
|
|
|
fluent::fluent_messages(input)
|
|
|
|
}
|