Skip to content

Commit c9fbaab

Browse files
committed
Reflow MirPhase comments.
Currently many of them exceed 100 chars, which makes them painful to read on a terminal that is 100 chars wide.
1 parent 5986ff0 commit c9fbaab

File tree

1 file changed

+25
-22
lines changed

1 file changed

+25
-22
lines changed

compiler/rustc_middle/src/mir/syntax.rs

+25-22
Original file line numberDiff line numberDiff line change
@@ -53,34 +53,36 @@ pub enum MirPhase {
5353
/// sequences of statements that would generally be subject to constant promotion are
5454
/// semantically constants, while in analysis MIR all constants are explicit.
5555
///
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.
5758
///
5859
/// This is the version of MIR used by borrowck and friends.
5960
Analysis(AnalysisPhase),
6061
/// The MIR used for CTFE, optimizations, and codegen.
6162
///
6263
/// The semantic changes that occur in the lowering from analysis to runtime MIR are as follows:
6364
///
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.
8486
///
8587
/// Also note that the lint pass which reports eg `200_u8 + 200_u8` as an error is run as a part
8688
/// of analysis to runtime MIR lowering. To ensure lints are reported reliably, this means that
@@ -111,7 +113,8 @@ pub enum AnalysisPhase {
111113
/// * [`TerminatorKind::FalseEdge`]
112114
/// * [`StatementKind::FakeRead`]
113115
/// * [`StatementKind::AscribeUserType`]
114-
/// * [`StatementKind::Coverage`] with [`CoverageKind::BlockMarker`] or [`CoverageKind::SpanMarker`]
116+
/// * [`StatementKind::Coverage`] with [`CoverageKind::BlockMarker`] or
117+
/// [`CoverageKind::SpanMarker`]
115118
/// * [`Rvalue::Ref`] with `BorrowKind::Fake`
116119
/// * [`CastKind::PointerCoercion`] with any of the following:
117120
/// * [`PointerCoercion::ArrayToPointer`]

0 commit comments

Comments
 (0)