File: field-destruction-order.rs

package info (click to toggle)
rustc 1.85.0%2Bdfsg3-1
  • links: PTS, VCS
  • area: main
  • in suites: experimental, sid, trixie
  • size: 893,396 kB
  • sloc: xml: 158,127; python: 35,830; javascript: 19,497; cpp: 19,002; sh: 17,245; ansic: 13,127; asm: 4,376; makefile: 1,051; perl: 29; lisp: 29; ruby: 19; sql: 11
file content (47 lines) | stat: -rw-r--r-- 1,233 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
#![allow(dead_code)]
#![allow(non_upper_case_globals)]

// In theory, it doesn't matter what order destructors are run in for rust
// because we have explicit ownership of values meaning that there's no need to
// run one before another. With unsafe code, however, there may be a safe
// interface which relies on fields having their destructors run in a particular
// order. At the time of this writing, std::rt::sched::Scheduler is an example
// of a structure which contains unsafe handles to FFI-like types, and the
// destruction order of the fields matters in the sense that some handles need
// to get destroyed before others.
//
// In C++, destruction order happens bottom-to-top in order of field
// declarations, but we currently run them top-to-bottom. I don't think the
// order really matters that much as long as we define what it is.


struct A;
struct B;
struct C {
    a: A,
    b: B,
}

static mut hit: bool = false;

impl Drop for A {
    fn drop(&mut self) {
        unsafe {
            assert!(!hit);
            hit = true;
        }
    }
}

impl Drop for B {
    fn drop(&mut self) {
        unsafe {
            assert!(hit);
        }
    }
}

pub fn main() {
    let _c = C { a: A, b: B };
}