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
|
2023-11-13 07:39:17 -05:00
|
|
|
#![allow(internal_features)]
|
2024-02-06 09:51:39 +11:00
|
|
|
#![allow(rustc::diagnostic_outside_of_impl)]
|
2023-11-13 07:39:17 -05:00
|
|
|
#![doc(rust_logo)]
|
2021-03-04 13:06:01 +01:00
|
|
|
#![feature(assert_matches)]
|
2016-02-11 18:05:28 +02:00
|
|
|
#![feature(box_patterns)]
|
2020-04-27 19:01:30 +02:00
|
|
|
#![feature(decl_macro)]
|
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(if_let_guard)]
|
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(never_type)]
|
|
|
|
#![feature(rustdoc_internals)]
|
2021-05-16 18:53:20 +02:00
|
|
|
#![feature(slice_ptr_get)]
|
2024-11-30 18:06:33 +01:00
|
|
|
#![feature(strict_overflow_ops)]
|
2020-12-30 18:48:40 +01:00
|
|
|
#![feature(trait_alias)]
|
|
|
|
#![feature(try_blocks)]
|
2024-10-14 14:46:44 -07:00
|
|
|
#![feature(unqualified_local_imports)]
|
2022-05-29 01:19:52 -07:00
|
|
|
#![feature(yeet_expr)]
|
2024-10-14 14:46:44 -07:00
|
|
|
#![warn(unqualified_local_imports)]
|
2024-08-30 16:36:04 +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
|
2015-08-18 17:59:21 -04:00
|
|
|
|
2024-05-24 01:33:13 -07:00
|
|
|
pub mod check_consts;
|
2018-08-24 16:39:25 +02:00
|
|
|
pub mod const_eval;
|
2022-06-28 21:26:05 -07:00
|
|
|
mod errors;
|
2017-12-14 11:36:28 +01:00
|
|
|
pub mod interpret;
|
2017-03-09 20:10:05 +02:00
|
|
|
pub mod util;
|
2016-09-15 18:18:40 -07:00
|
|
|
|
2023-05-19 16:03:35 -04:00
|
|
|
use std::sync::atomic::AtomicBool;
|
|
|
|
|
2023-09-22 16:26:20 +00:00
|
|
|
use rustc_middle::ty;
|
|
|
|
use rustc_middle::util::Providers;
|
2017-02-20 03:55:28 +02:00
|
|
|
|
2024-09-23 11:57:12 +02:00
|
|
|
pub use self::errors::ReportErrorExt;
|
|
|
|
|
2023-11-22 09:53:07 +11:00
|
|
|
rustc_fluent_macro::fluent_messages! { "../messages.ftl" }
|
2022-10-13 10:13:02 +01:00
|
|
|
|
2023-09-22 16:26:20 +00:00
|
|
|
pub fn provide(providers: &mut Providers) {
|
2020-01-01 18:06:00 +01:00
|
|
|
const_eval::provide(providers);
|
2024-03-20 17:45:14 +00:00
|
|
|
providers.tag_for_variant = const_eval::tag_for_variant_provider;
|
2020-09-19 10:57:14 +02:00
|
|
|
providers.eval_to_const_value_raw = const_eval::eval_to_const_value_raw_provider;
|
2020-08-20 18:55:07 +02:00
|
|
|
providers.eval_to_allocation_raw = const_eval::eval_to_allocation_raw_provider;
|
2023-10-10 08:52:21 +00:00
|
|
|
providers.eval_static_initializer = const_eval::eval_static_initializer_provider;
|
2023-10-30 09:58:54 +00:00
|
|
|
providers.hooks.const_caller_location = util::caller_location::const_caller_location_provider;
|
2024-11-19 20:10:42 +01:00
|
|
|
providers.eval_to_valtree = |tcx, ty::PseudoCanonicalInput { typing_env, value }| {
|
|
|
|
const_eval::eval_to_valtree(tcx, typing_env, value)
|
2021-02-22 14:09:24 +00:00
|
|
|
};
|
2023-10-31 17:38:41 +00:00
|
|
|
providers.hooks.try_destructure_mir_constant_for_user_output =
|
|
|
|
const_eval::try_destructure_mir_constant_for_user_output;
|
2025-02-02 11:46:21 +01:00
|
|
|
providers.valtree_to_const_val =
|
|
|
|
|tcx, cv| const_eval::valtree_to_const_value(tcx, ty::TypingEnv::fully_monomorphized(), cv);
|
2023-02-26 21:50:19 +00:00
|
|
|
providers.check_validity_requirement = |tcx, (init_kind, param_env_and_ty)| {
|
|
|
|
util::check_validity_requirement(tcx, init_kind, param_env_and_ty)
|
2023-01-22 17:06:28 -05:00
|
|
|
};
|
2017-03-14 12:22:38 -07:00
|
|
|
}
|
2023-05-19 16:03:35 -04:00
|
|
|
|
|
|
|
/// `rustc_driver::main` installs a handler that will set this to `true` if
|
|
|
|
/// the compiler has been sent a request to shut down, such as by a Ctrl-C.
|
|
|
|
/// This static lives here because it is only read by the interpreter.
|
|
|
|
pub static CTRL_C_RECEIVED: AtomicBool = AtomicBool::new(false);
|