Discuss cleanup blocks and span_bug on Abort

This commit is contained in:
Dylan MacKenzie 2020-10-04 10:39:12 -07:00
parent 14c3705c6c
commit 25fdbaff44

View File

@ -434,11 +434,13 @@ impl Visitor<'tcx> for Validator<'mir, 'tcx> {
fn visit_basic_block_data(&mut self, bb: BasicBlock, block: &BasicBlockData<'tcx>) { fn visit_basic_block_data(&mut self, bb: BasicBlock, block: &BasicBlockData<'tcx>) {
trace!("visit_basic_block_data: bb={:?} is_cleanup={:?}", bb, block.is_cleanup); trace!("visit_basic_block_data: bb={:?} is_cleanup={:?}", bb, block.is_cleanup);
// Just as the old checker did, we skip const-checking basic blocks on the unwind path. // We don't const-check basic blocks on the cleanup path since we never unwind during
// These blocks often drop locals that would otherwise be returned from the function. // const-eval: a panic causes an immediate compile error. In other words, cleanup blocks
// are unreachable during const-eval.
// //
// FIXME: This shouldn't be unsound since a panic at compile time will cause a compiler // We can't be more conservative (e.g., by const-checking cleanup blocks anyways) because
// error anyway, but maybe we should do more here? // locals that would never be dropped during normal execution are sometimes dropped during
// unwinding, which means backwards-incompatible live-drop errors.
if block.is_cleanup { if block.is_cleanup {
return; return;
} }
@ -879,8 +881,11 @@ fn visit_terminator(&mut self, terminator: &Terminator<'tcx>, location: Location
self.check_op(ops::Generator(hir::GeneratorKind::Gen)) self.check_op(ops::Generator(hir::GeneratorKind::Gen))
} }
TerminatorKind::Abort TerminatorKind::Abort => {
| TerminatorKind::Assert { .. } span_bug!(self.span, "`Abort` terminator outside of cleanup block")
}
TerminatorKind::Assert { .. }
| TerminatorKind::FalseEdge { .. } | TerminatorKind::FalseEdge { .. }
| TerminatorKind::FalseUnwind { .. } | TerminatorKind::FalseUnwind { .. }
| TerminatorKind::Goto { .. } | TerminatorKind::Goto { .. }