From 698f8c2f01ea549d77d7dc3338a12e04c11057b9 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Wed, 17 Apr 2024 14:02:58 +0200 Subject: Adding upstream version 1.64.0+dfsg1. Signed-off-by: Daniel Baumann --- .../cleanup-rvalue-temp-during-incomplete-alloc.rs | 47 ++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 src/test/ui/cleanup-rvalue-temp-during-incomplete-alloc.rs (limited to 'src/test/ui/cleanup-rvalue-temp-during-incomplete-alloc.rs') diff --git a/src/test/ui/cleanup-rvalue-temp-during-incomplete-alloc.rs b/src/test/ui/cleanup-rvalue-temp-during-incomplete-alloc.rs new file mode 100644 index 000000000..6cd3781b7 --- /dev/null +++ b/src/test/ui/cleanup-rvalue-temp-during-incomplete-alloc.rs @@ -0,0 +1,47 @@ +// run-pass +// needs-unwind + +#![allow(unused_must_use)] +#![allow(dead_code)] +#![allow(unused_variables)] +// Test cleanup of rvalue temporary that occurs while `box` construction +// is in progress. This scenario revealed a rather terrible bug. The +// ingredients are: +// +// 1. Partial cleanup of `box` is in scope, +// 2. cleanup of return value from `get_bar()` is in scope, +// 3. do_it() panics. +// +// This led to a bug because `the top-most frame that was to be +// cleaned (which happens to be the partial cleanup of `box`) required +// multiple basic blocks, which led to us dropping part of the cleanup +// from the top-most frame. +// +// It's unclear how likely such a bug is to recur, but it seems like a +// scenario worth testing. + +// ignore-emscripten no threads support + +use std::thread; + +enum Conzabble { + Bickwick(Foo) +} + +struct Foo { field: Box } + +fn do_it(x: &[usize]) -> Foo { + panic!() +} + +fn get_bar(x: usize) -> Vec { vec![x * 2] } + +pub fn fails() { + let x = 2; + let mut y: Vec> = Vec::new(); + y.push(Box::new(Conzabble::Bickwick(do_it(&get_bar(x))))); +} + +pub fn main() { + thread::spawn(fails).join(); +} -- cgit v1.2.3