Adding upstream version 1.64.0+dfsg1.upstream/1.64.0+dfsg1

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 47 insertions, 0 deletions

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<usize> }
+
+fn do_it(x: &[usize]) -> Foo {
+    panic!()
+}
+
+fn get_bar(x: usize) -> Vec<usize> { vec![x * 2] }
+
+pub fn fails() {
+    let x = 2;
+    let mut y: Vec<Box<_>> = Vec::new();
+    y.push(Box::new(Conzabble::Bickwick(do_it(&get_bar(x)))));
+}
+
+pub fn main() {
+    thread::spawn(fails).join();
+}