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
|
2023-11-13 12:39:17 +00:00
|
|
|
#![allow(internal_features)]
|
2024-02-05 22:51:39 +00:00
|
|
|
#![allow(rustc::diagnostic_outside_of_impl)]
|
2024-09-23 09:57:12 +00:00
|
|
|
#![cfg_attr(not(bootstrap), feature(unqualified_local_imports))]
|
|
|
|
#![cfg_attr(not(bootstrap), warn(unqualified_local_imports))]
|
2023-11-13 12:39:17 +00:00
|
|
|
#![doc(rust_logo)]
|
2021-03-04 12:06:01 +00:00
|
|
|
#![feature(assert_matches)]
|
2016-02-11 16:05:28 +00:00
|
|
|
#![feature(box_patterns)]
|
2020-04-27 17:01:30 +00: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 03:49:36 +00:00
|
|
|
#![feature(if_let_guard)]
|
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(never_type)]
|
|
|
|
#![feature(rustdoc_internals)]
|
2021-05-16 16:53:20 +00:00
|
|
|
#![feature(slice_ptr_get)]
|
2024-03-09 17:13:50 +00:00
|
|
|
#![feature(strict_provenance)]
|
2020-12-30 17:48:40 +00:00
|
|
|
#![feature(trait_alias)]
|
|
|
|
#![feature(try_blocks)]
|
2022-05-29 08:19:52 +00:00
|
|
|
#![feature(yeet_expr)]
|
2024-08-30 06:36:04 +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
|
2015-08-18 21:59:21 +00:00
|
|
|
|
2024-05-24 08:33:13 +00:00
|
|
|
pub mod check_consts;
|
2018-08-24 14:39:25 +00:00
|
|
|
pub mod const_eval;
|
2022-06-29 04:26:05 +00:00
|
|
|
mod errors;
|
2017-12-14 10:36:28 +00:00
|
|
|
pub mod interpret;
|
2017-03-09 18:10:05 +00:00
|
|
|
pub mod util;
|
2016-09-16 01:18:40 +00:00
|
|
|
|
2023-05-19 20:03:35 +00: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 01:55:28 +00:00
|
|
|
|
2024-09-23 09:57:12 +00:00
|
|
|
pub use self::errors::ReportErrorExt;
|
|
|
|
|
2023-11-21 22:53:07 +00:00
|
|
|
rustc_fluent_macro::fluent_messages! { "../messages.ftl" }
|
2022-10-13 09:13:02 +00:00
|
|
|
|
2023-09-22 16:26:20 +00:00
|
|
|
pub fn provide(providers: &mut Providers) {
|
2020-01-01 17:06:00 +00: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 08:57:14 +00:00
|
|
|
providers.eval_to_const_value_raw = const_eval::eval_to_const_value_raw_provider;
|
2020-08-20 16:55:07 +00: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;
|
2022-04-12 16:14:28 +00:00
|
|
|
providers.eval_to_valtree = |tcx, param_env_and_value| {
|
2021-02-22 14:09:24 +00:00
|
|
|
let (param_env, raw) = param_env_and_value.into_parts();
|
2022-04-12 16:14:28 +00:00
|
|
|
const_eval::eval_to_valtree(tcx, param_env, raw)
|
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;
|
2022-02-16 09:56:01 +00:00
|
|
|
providers.valtree_to_const_val = |tcx, (ty, valtree)| {
|
|
|
|
const_eval::valtree_to_const_value(tcx, ty::ParamEnv::empty().and(ty), valtree)
|
2020-07-01 09:41:38 +00:00
|
|
|
};
|
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 22:06:28 +00:00
|
|
|
};
|
2017-03-14 19:22:38 +00:00
|
|
|
}
|
2023-05-19 20:03:35 +00: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);
|