@@ -53,34 +53,36 @@ pub enum MirPhase {
53
53
/// sequences of statements that would generally be subject to constant promotion are
54
54
/// semantically constants, while in analysis MIR all constants are explicit.
55
55
///
56
- /// The result of const promotion is available from the `mir_promoted` and `promoted_mir` queries.
56
+ /// The result of const promotion is available from the `mir_promoted` and `promoted_mir`
57
+ /// queries.
57
58
///
58
59
/// This is the version of MIR used by borrowck and friends.
59
60
Analysis ( AnalysisPhase ) ,
60
61
/// The MIR used for CTFE, optimizations, and codegen.
61
62
///
62
63
/// The semantic changes that occur in the lowering from analysis to runtime MIR are as follows:
63
64
///
64
- /// - Drops: In analysis MIR, `Drop` terminators represent *conditional* drops; roughly speaking,
65
- /// if dataflow analysis determines that the place being dropped is uninitialized, the drop will
66
- /// not be executed. The exact semantics of this aren't written down anywhere, which means they
67
- /// are essentially "what drop elaboration does." In runtime MIR, the drops are unconditional;
68
- /// when a `Drop` terminator is reached, if the type has drop glue that drop glue is always
69
- /// executed. This may be UB if the underlying place is not initialized.
70
- /// - Packed drops: Places might in general be misaligned - in most cases this is UB, the exception
71
- /// is fields of packed structs. In analysis MIR, `Drop(P)` for a `P` that might be misaligned
72
- /// for this reason implicitly moves `P` to a temporary before dropping. Runtime MIR has no such
73
- /// rules, and dropping a misaligned place is simply UB.
74
- /// - Unwinding: in analysis MIR, unwinding from a function which may not unwind aborts. In runtime
75
- /// MIR, this is UB.
76
- /// - Retags: If `-Zmir-emit-retag` is enabled, analysis MIR has "implicit" retags in the same way
77
- /// that Rust itself has them. Where exactly these are is generally subject to change, and so we
78
- /// don't document this here. Runtime MIR has most retags explicit (though implicit retags
79
- /// can still occur at `Rvalue::{Ref,AddrOf}`).
80
- /// - Coroutine bodies: In analysis MIR, locals may actually be behind a pointer that user code has
81
- /// access to. This occurs in coroutine bodies. Such locals do not behave like other locals,
82
- /// because they eg may be aliased in surprising ways. Runtime MIR has no such special locals -
83
- /// all coroutine bodies are lowered and so all places that look like locals really are locals.
65
+ /// - Drops: In analysis MIR, `Drop` terminators represent *conditional* drops; roughly
66
+ /// speaking, if dataflow analysis determines that the place being dropped is uninitialized,
67
+ /// the drop will not be executed. The exact semantics of this aren't written down anywhere,
68
+ /// which means they are essentially "what drop elaboration does." In runtime MIR, the drops
69
+ /// are unconditional; when a `Drop` terminator is reached, if the type has drop glue that
70
+ /// drop glue is always executed. This may be UB if the underlying place is not initialized.
71
+ /// - Packed drops: Places might in general be misaligned - in most cases this is UB, the
72
+ /// exception is fields of packed structs. In analysis MIR, `Drop(P)` for a `P` that might be
73
+ /// misaligned for this reason implicitly moves `P` to a temporary before dropping. Runtime
74
+ /// MIR has no such rules, and dropping a misaligned place is simply UB.
75
+ /// - Unwinding: in analysis MIR, unwinding from a function which may not unwind aborts. In
76
+ /// runtime MIR, this is UB.
77
+ /// - Retags: If `-Zmir-emit-retag` is enabled, analysis MIR has "implicit" retags in the same
78
+ /// way that Rust itself has them. Where exactly these are is generally subject to change,
79
+ /// and so we don't document this here. Runtime MIR has most retags explicit (though implicit
80
+ /// retags can still occur at `Rvalue::{Ref,AddrOf}`).
81
+ /// - Coroutine bodies: In analysis MIR, locals may actually be behind a pointer that user code
82
+ /// has access to. This occurs in coroutine bodies. Such locals do not behave like other
83
+ /// locals, because they eg may be aliased in surprising ways. Runtime MIR has no such
84
+ /// special locals. All coroutine bodies are lowered and so all places that look like locals
85
+ /// really are locals.
84
86
///
85
87
/// Also note that the lint pass which reports eg `200_u8 + 200_u8` as an error is run as a part
86
88
/// of analysis to runtime MIR lowering. To ensure lints are reported reliably, this means that
@@ -111,7 +113,8 @@ pub enum AnalysisPhase {
111
113
/// * [`TerminatorKind::FalseEdge`]
112
114
/// * [`StatementKind::FakeRead`]
113
115
/// * [`StatementKind::AscribeUserType`]
114
- /// * [`StatementKind::Coverage`] with [`CoverageKind::BlockMarker`] or [`CoverageKind::SpanMarker`]
116
+ /// * [`StatementKind::Coverage`] with [`CoverageKind::BlockMarker`] or
117
+ /// [`CoverageKind::SpanMarker`]
115
118
/// * [`Rvalue::Ref`] with `BorrowKind::Fake`
116
119
/// * [`CastKind::PointerCoercion`] with any of the following:
117
120
/// * [`PointerCoercion::ArrayToPointer`]
0 commit comments