File: cleanup-rvalue-temp-during-incomplete-alloc.rs

package info (click to toggle)
rustc-web 1.78.0%2Bdfsg1-2~deb12u3
  • links: PTS, VCS
  • area: main
  • in suites: bookworm
  • size: 1,245,420 kB
  • sloc: xml: 147,985; javascript: 18,022; sh: 11,083; python: 10,265; ansic: 6,172; cpp: 5,023; asm: 4,390; makefile: 4,269
file content (47 lines) | stat: -rw-r--r-- 1,159 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
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();
}