rust/src/test/run-pass/issue-2735-2.rs

// This test should behave exactly like issue-2735-3
struct defer {
    b: &mut bool,
    drop { *(self.b) = true; }
}

fn defer(b: &r/mut bool) -> defer/&r {
    defer {
        b: b
    }
}

fn main() {
    let mut dtor_ran = false;
    let _  = defer(&mut dtor_ran);
    assert(dtor_ran);
}
Make let _ = e; have the same semantics as e; The first case was getting treated like a variable binding, meaning that if e had a destructor, it wouldn't run until the end of the enclosing scope. To me it seems less confusing for let _ = e; and e; to work exactly the same way, so now, the destructor for e runs immediately in both cases. 2012-08-08 15:36:38 -07:00			`// This test should behave exactly like issue-2735-3`
Remove the class keyword 2012-08-15 18:46:55 -07:00			`struct defer {`
Remove 'let' syntax for struct fields 2012-09-06 19:40:15 -07:00			`b: &mut bool,`
Make let _ = e; have the same semantics as e; The first case was getting treated like a variable binding, meaning that if e had a destructor, it wouldn't run until the end of the enclosing scope. To me it seems less confusing for let _ = e; and e; to work exactly the same way, so now, the destructor for e runs immediately in both cases. 2012-08-08 15:36:38 -07:00			`drop { *(self.b) = true; }`
			`}`

Remove struct ctors 2012-09-05 15:58:43 -07:00			`fn defer(b: &r/mut bool) -> defer/&r {`
			`defer {`
			`b: b`
			`}`
			`}`

Make let _ = e; have the same semantics as e; The first case was getting treated like a variable binding, meaning that if e had a destructor, it wouldn't run until the end of the enclosing scope. To me it seems less confusing for let _ = e; and e; to work exactly the same way, so now, the destructor for e runs immediately in both cases. 2012-08-08 15:36:38 -07:00			`fn main() {`
			`let mut dtor_ran = false;`
			`let _ = defer(&mut dtor_ran);`
			`assert(dtor_ran);`
			`}`