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 03:49:36 +00:00
|
|
|
// tidy-alphabetical-start
|
|
|
|
#![allow(internal_features)]
|
|
|
|
#![feature(iter_intersperse)]
|
2022-08-20 18:40:08 +00: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 03:49:36 +00:00
|
|
|
#![feature(map_many_mut)]
|
2022-06-10 14:50:06 +00:00
|
|
|
#![feature(rustc_attrs)]
|
2024-08-30 01:02:18 +00: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 03:49:36 +00:00
|
|
|
// tidy-alphabetical-end
|
2019-11-29 21:05:28 +00:00
|
|
|
|
2022-08-19 13:34:13 +00:00
|
|
|
pub mod errors;
|
2020-06-14 00:00:00 +00:00
|
|
|
|
2019-11-12 13:30:40 +00:00
|
|
|
pub mod utils;
|
2020-08-13 19:41:52 +00: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 20:45:26 +00:00
|
|
|
pub mod parse;
|
2019-11-29 21:05:28 +00:00
|
|
|
|
2023-05-17 12:28:04 +00:00
|
|
|
pub mod code_stats;
|
2019-12-17 12:22:55 +00:00
|
|
|
#[macro_use]
|
2019-11-29 21:05:28 +00:00
|
|
|
pub mod config;
|
2020-11-14 02:02:03 +00:00
|
|
|
pub mod cstore;
|
2019-11-29 21:05:28 +00:00
|
|
|
pub mod filesearch;
|
2019-12-17 12:22:55 +00:00
|
|
|
mod options;
|
2019-11-29 21:05:28 +00:00
|
|
|
pub mod search_paths;
|
|
|
|
|
|
|
|
mod session;
|
|
|
|
pub use session::*;
|
2020-03-12 23:07:58 +00:00
|
|
|
|
|
|
|
pub mod output;
|
2020-04-10 20:42:19 +00:00
|
|
|
|
|
|
|
pub use getopts;
|
2021-06-25 23:48:26 +00:00
|
|
|
|
2023-11-21 22:53:07 +00:00
|
|
|
rustc_fluent_macro::fluent_messages! { "../messages.ftl" }
|
2022-10-13 09:13:02 +00:00
|
|
|
|
2021-06-25 23:48:26 +00: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 02:02:03 +00:00
|
|
|
pub trait HashStableContext: rustc_ast::HashStableContext + rustc_hir::HashStableContext {}
|