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 --- .../ui/structs-enums/field-destruction-order.rs | 47 ++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 src/test/ui/structs-enums/field-destruction-order.rs (limited to 'src/test/ui/structs-enums/field-destruction-order.rs') diff --git a/src/test/ui/structs-enums/field-destruction-order.rs b/src/test/ui/structs-enums/field-destruction-order.rs new file mode 100644 index 000000000..a75a742d9 --- /dev/null +++ b/src/test/ui/structs-enums/field-destruction-order.rs @@ -0,0 +1,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 }; +} -- cgit v1.2.3