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)]
|
|
|
|
|
#![feature(iter_intersperse)]
|
2022-08-20 20:40:08 +02:00
|
|
|
#![feature(let_chains)]
|
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(map_many_mut)]
|
2022-06-10 15:50:06 +01:00
|
|
|
#![feature(rustc_attrs)]
|
2024-08-30 11:02:18 +10:00
|
|
|
#![warn(unreachable_pub)]
|
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
|
2019-11-29 16:05:28 -05:00
|
|
|
|
2022-08-19 15:34:13 +02:00
|
|
|
pub mod errors;
|
2020-06-14 00:00:00 +00:00
|
|
|
|
2019-11-12 08:30:40 -05:00
|
|
|
pub mod utils;
|
2020-08-13 15:41:52 -04:00
|
|
|
pub use lint::{declare_lint, declare_lint_pass, declare_tool_lint, impl_lint_pass};
|
|
|
|
|
pub use rustc_lint_defs as lint;
|
2019-11-29 15:45:26 -05:00
|
|
|
pub mod parse;
|
2019-11-29 16:05:28 -05:00
|
|
|
|
2023-05-17 12:28:04 +00:00
|
|
|
pub mod code_stats;
|
2019-12-17 23:22:55 +11:00
|
|
|
#[macro_use]
|
2019-11-29 16:05:28 -05:00
|
|
|
pub mod config;
|
2020-11-14 03:02:03 +01:00
|
|
|
pub mod cstore;
|
2019-11-29 16:05:28 -05:00
|
|
|
pub mod filesearch;
|
2019-12-17 23:22:55 +11:00
|
|
|
mod options;
|
2019-11-29 16:05:28 -05:00
|
|
|
pub mod search_paths;
|
|
|
|
|
|
|
|
|
|
mod session;
|
|
|
|
|
pub use session::*;
|
2020-03-12 18:07:58 -05:00
|
|
|
|
|
|
|
|
pub mod output;
|
2020-04-10 22:42:19 +02:00
|
|
|
|
|
|
|
|
pub use getopts;
|
2021-06-25 18:48:26 -05:00
|
|
|
|
2023-11-22 09:53:07 +11:00
|
|
|
rustc_fluent_macro::fluent_messages! { "../messages.ftl" }
|
2022-10-13 10:13:02 +01:00
|
|
|
|
2021-06-25 18:48:26 -05:00
|
|
|
/// Requirements for a `StableHashingContext` to be used in this crate.
|
|
|
|
|
/// This is a hack to allow using the `HashStable_Generic` derive macro
|
|
|
|
|
/// instead of implementing everything in `rustc_middle`.
|
2020-11-14 03:02:03 +01:00
|
|
|
pub trait HashStableContext: rustc_ast::HashStableContext + rustc_hir::HashStableContext {}
|