Closed celinval closed 1 year ago
Note that the cleanup logic seems correct when there is no unwinding:
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0 OR MIT
#[derive(PartialEq, Eq)]
struct S {
a: u8,
}
impl Drop for S {
fn drop(&mut self) {
assert!(false, "A1: This should still fail during cleanup");
}
}
pub fn main() {
let lhs = S { a: 42 };
let rhs = S { a: 0 };
assert!(lhs != rhs, "A2: A true statement. Succeed");
}
Result is:
[<S as std::ops::Drop>::drop.assertion.1] line 21 A1: This should still fail during cleanup: FAILURE
...
[main.assertion.2] line 22 resume instruction: SUCCESS
[main.assertion.1] line 25 A2: A true statement. Succeed: SUCCESS
There are actually two different bugs reported in this issue.
We'll handle the bug #1
on issue #636 and we'll leave this issue to track bug #2
We don't support stack unwinding yet. I created a feature request (#692) to track that. I'll leave this issue open for now since it is a valid use case that we should ensure gets covered.
I don't think this is tracking anything not in #692 and #267, closing.
I was playing with the assertion codegen to understand how we were handling cleanup after a failure. I created the following test case:
using the following command line invocation:
I expected to see this happen: Assertions A1 and A2 should fail, but assertions A3 should be unreachable.
Instead, this happened: RMC entered an infinite loop.
I also tested the code with --unwind 0. The result is incorrect. A2 and A3 fail, but A1 doesn't.