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
|
2024-08-11 12:10:36 -04:00
|
|
|
#![feature(assert_matches)]
|
2021-01-05 19:53:07 +01:00
|
|
|
#![feature(associated_type_defaults)]
|
|
|
|
#![feature(box_patterns)]
|
|
|
|
#![feature(exact_size_is_empty)]
|
2024-09-24 14:25:16 -07:00
|
|
|
#![feature(file_buffered)]
|
2023-01-21 22:28:54 +00:00
|
|
|
#![feature(let_chains)]
|
Simplify dataflow `SwitchInt` handling.
Current `SwitchInt` handling has complicated control flow.
- The dataflow engine calls `Analysis::apply_switch_int_edge_effects`,
passing in an "applier" that impls `SwitchIntEdgeEffects`.
- `apply_switch_int_edge_effects` possibly calls `apply` on the applier,
passing it a closure.
- The `apply` method calls the closure on each `SwitchInt` edge.
- The closure operates on the edge.
I.e. control flow goes from the engine, to the analysis, to the applier
(which came from the engine), to the closure (which came from the
analysis). It took me a while to work this out.
This commit changes to a simpler structure that maintains the important
characteristics.
- The dataflow engine calls `Analysis::get_switch_int_data`.
- `get_switch_int_data` returns an `Option<Self::SwitchIntData>` value.
- If that returned value was `Some`, the dataflow engine calls
`Analysis::apply_switch_int_edge_effect` on each edge, passing the
`Self::SwitchIntData` value.
- `Analysis::apply_switch_int_edge_effect` operates on the edge.
I.e. control flow goes from the engine, to the analysis, to the
engine, to the analysis.
Added:
- The `Analysis::SwitchIntData` assoc type and the
`Analysis::get_switch_int_data` method. Both only need to be
defined by analyses that look at `SwitchInt` terminators.
- The `MaybePlacesSwitchIntData` struct, which has three fields.
Changes:
- `Analysis::apply_switch_int_edge_effects` becomes
`Analysis::apply_switch_int_edge_effect`, which is a little simpler
because it's dealing with a single edge instead of all edges.
Removed:
- The `SwitchIntEdgeEffects` trait, and its two impls:
`BackwardSwitchIntEdgeEffectsApplier` (which has six fields) and
`ForwardSwitchIntEdgeEffectsApplier` structs (which has four fields).
- The closure.
The new structure is more concise and simpler.
2024-11-21 10:20:30 +11:00
|
|
|
#![feature(never_type)]
|
2023-11-23 18:19:43 +11:00
|
|
|
#![feature(try_blocks)]
|
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
|
2021-01-05 19:53:07 +01:00
|
|
|
|
2023-11-22 08:49:37 +11:00
|
|
|
use rustc_middle::ty;
|
Revised mir-dataflow.
Incorporates many fixes contributed by arielb1.
----
revise borrowck::mir::dataflow code to allow varying domain for bitvectors.
This particular code implements the `BitDenotation` trait for three
analyses:
* `MovingOutStatements`, which, like `borrowck::move_data`, maps each
bit-index to a move instruction, and a 1 means "the effect of this
move reaches this point" (and the assigned l-value, if a scoped
declaration, is still in scope).
* `MaybeInitializedLvals`, which maps each bit-index to an l-value.
A 1 means "there exists a control flow path to this point that
initializes the associated l-value."
* `MaybeUninitializedLvals`, which maps each bit-index to an l-value
A 1 means "there exists a control flow path to this point that
de-initializes the associated l-value."
----
Revised `graphviz` dataflow-rendering support in `borrowck::mir`.
One big difference is that this code is now parameterized over the
`BitDenotation`, so that it can be used to render dataflow results
independent of how the dataflow bitvectors are interpreted; see where
reference to `MoveOut` is replaced by the type parameter `D`.
----
Factor out routine to query subattributes in `#[rustc_mir(..)]`.
(Later commits build upon this for some unit testing and instrumentation.)
----
thread through a tcx so that I can query types of lvalues as part of analysis.
----
Revised `BitDenotation::Ctxt`, allowing variation beyond `MoveData`.
The main motivation is to ease threading through a `TyCtxt`.
(In hindsight it might have been better to instead attach the `TyCtxt`
to each of the different dataflow implementations, but that would
require e.g. switching away from having a `Default` impl, so I am
leaving that experiment for another time.)
2016-05-02 15:50:27 +02:00
|
|
|
|
2024-01-20 16:52:18 -03:00
|
|
|
// Please change the public `use` directives cautiously, as they might be used by external tools.
|
|
|
|
// See issue #120130.
|
2021-01-01 01:53:25 +01:00
|
|
|
pub use self::drop_flag_effects::{
|
2025-02-14 15:30:51 +11:00
|
|
|
DropFlagState, drop_flag_effects_for_function_entry, drop_flag_effects_for_location,
|
2023-10-01 08:47:12 +00:00
|
|
|
move_path_children_matching, on_all_children_bits, on_lookup_result_bits,
|
2021-01-01 01:53:25 +01:00
|
|
|
};
|
2020-02-28 21:55:41 -08:00
|
|
|
pub use self::framework::{
|
2024-11-26 14:21:17 +11:00
|
|
|
Analysis, Backward, Direction, EntryStates, Forward, GenKill, JoinSemiLattice, MaybeReachable,
|
Simplify dataflow `SwitchInt` handling.
Current `SwitchInt` handling has complicated control flow.
- The dataflow engine calls `Analysis::apply_switch_int_edge_effects`,
passing in an "applier" that impls `SwitchIntEdgeEffects`.
- `apply_switch_int_edge_effects` possibly calls `apply` on the applier,
passing it a closure.
- The `apply` method calls the closure on each `SwitchInt` edge.
- The closure operates on the edge.
I.e. control flow goes from the engine, to the analysis, to the applier
(which came from the engine), to the closure (which came from the
analysis). It took me a while to work this out.
This commit changes to a simpler structure that maintains the important
characteristics.
- The dataflow engine calls `Analysis::get_switch_int_data`.
- `get_switch_int_data` returns an `Option<Self::SwitchIntData>` value.
- If that returned value was `Some`, the dataflow engine calls
`Analysis::apply_switch_int_edge_effect` on each edge, passing the
`Self::SwitchIntData` value.
- `Analysis::apply_switch_int_edge_effect` operates on the edge.
I.e. control flow goes from the engine, to the analysis, to the
engine, to the analysis.
Added:
- The `Analysis::SwitchIntData` assoc type and the
`Analysis::get_switch_int_data` method. Both only need to be
defined by analyses that look at `SwitchInt` terminators.
- The `MaybePlacesSwitchIntData` struct, which has three fields.
Changes:
- `Analysis::apply_switch_int_edge_effects` becomes
`Analysis::apply_switch_int_edge_effect`, which is a little simpler
because it's dealing with a single edge instead of all edges.
Removed:
- The `SwitchIntEdgeEffects` trait, and its two impls:
`BackwardSwitchIntEdgeEffectsApplier` (which has six fields) and
`ForwardSwitchIntEdgeEffectsApplier` structs (which has four fields).
- The closure.
The new structure is more concise and simpler.
2024-11-21 10:20:30 +11:00
|
|
|
Results, ResultsCursor, ResultsVisitor, fmt, graphviz, lattice, visit_results,
|
2023-11-22 10:25:52 +11:00
|
|
|
};
|
2017-07-04 12:38:48 +02:00
|
|
|
use self::move_paths::MoveData;
|
|
|
|
|
2023-01-12 20:04:42 +00:00
|
|
|
pub mod debuginfo;
|
2024-11-25 15:38:54 +11:00
|
|
|
mod drop_flag_effects;
|
2022-08-19 10:21:14 +01:00
|
|
|
mod errors;
|
2020-03-02 09:43:18 -08:00
|
|
|
mod framework;
|
2020-05-04 12:50:36 -07:00
|
|
|
pub mod impls;
|
2017-06-26 14:57:26 +02:00
|
|
|
pub mod move_paths;
|
2023-12-03 13:09:51 +00:00
|
|
|
pub mod points;
|
2021-01-05 19:53:07 +01:00
|
|
|
pub mod rustc_peek;
|
2024-11-25 15:38:54 +11:00
|
|
|
mod un_derefer;
|
2022-08-25 16:43:46 +00:00
|
|
|
pub mod value_analysis;
|
2017-06-26 14:57:26 +02:00
|
|
|
|
2023-11-22 09:53:07 +11:00
|
|
|
rustc_fluent_macro::fluent_messages! { "../messages.ftl" }
|
2022-10-13 10:13:02 +01:00
|
|
|
|
2024-11-20 11:27:35 +01:00
|
|
|
pub struct MoveDataTypingEnv<'tcx> {
|
2020-12-30 18:48:40 +01:00
|
|
|
pub move_data: MoveData<'tcx>,
|
2024-11-20 11:27:35 +01:00
|
|
|
pub typing_env: ty::TypingEnv<'tcx>,
|
2020-02-28 21:47:36 -08:00
|
|
|
}
|