]> git.proxmox.com Git - rustc.git/blame - src/test/run-pass/field-destruction-order.rs
New upstream version 1.19.0+dfsg1
[rustc.git] / src / test / run-pass / field-destruction-order.rs
CommitLineData
1a4d82fc
JJ
1// Copyright 2013 The Rust Project Developers. See the COPYRIGHT
2// file at the top-level directory of this distribution and at
3// http://rust-lang.org/COPYRIGHT.
4//
5// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
6// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
7// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
8// option. This file may not be copied, modified, or distributed
9// except according to those terms.
10
11// In theory, it doesn't matter what order destructors are run in for rust
12// because we have explicit ownership of values meaning that there's no need to
13// run one before another. With unsafe code, however, there may be a safe
14// interface which relies on fields having their destructors run in a particular
15// order. At the time of this writing, std::rt::sched::Scheduler is an example
16// of a structure which contains unsafe handles to FFI-like types, and the
17// destruction order of the fields matters in the sense that some handles need
18// to get destroyed before others.
19//
20// In C++, destruction order happens bottom-to-top in order of field
21// declarations, but we currently run them top-to-bottom. I don't think the
22// order really matters that much as long as we define what it is.
23
c34b1796 24
1a4d82fc
JJ
25struct A;
26struct B;
27struct C {
28 a: A,
29 b: B,
30}
31
32static mut hit: bool = false;
33
34impl Drop for A {
35 fn drop(&mut self) {
36 unsafe {
37 assert!(!hit);
38 hit = true;
39 }
40 }
41}
42
43impl Drop for B {
44 fn drop(&mut self) {
45 unsafe {
46 assert!(hit);
47 }
48 }
49}
50
51pub fn main() {
52 let _c = C { a: A, b: B };
53}