struct order of eval is (still) not well

[pnkfelix]

Executive summary:

This code fails in its assertion:

struct S { f0: String, _f1: u32 }

pub fn main() {
    const HI: &'static str = "Hello, world!";
    let s = HI.to_string();
    let s = S {
        f0: s.to_string(),
        ..S {
            f0: s,
            _f1: 23
        }
    };
    assert_eq!(HI, s.f0);
}

playpen link

---

Longer fun story:

You might think from our test suite that struct literal order of evaluation is being tested.

E.g. there are the two tests:

• /~https://github.com/rust-lang/rust/blob/master/src/test/run-pass/struct-order-of-eval-1.rs
• /~https://github.com/rust-lang/rust/blob/master/src/test/run-pass/struct-order-of-eval-2.rs

However, misbehavior I witnessed on my filling-drop work (namely, usize overflows, which I believe were signaled solely due to the recently landed arithmetic overflow work) led me to investigate these tests more closely.

Neither of them have assert! nor assert_eq! calls!

So essentially all we are testing in these two tests is that

1. the borrow checker does not complain, and
2. the resulting code does not segfault at runtime!

I.e., Very weak testing! (And also, totally bogus dynamic semantics.)

[pnkfelix]

Oh, in case its not clear: The only reason that the struct-order-of-eval-1.rs has been passing at all is because of: zeroing-on-drop.

I.e. the s.to_string() call runs on zeroed data, and naturally determines that we must be looking at an empty string.

[pnkfelix]

Here is a more robust way to be writing tests of order-of-evaluation: Actually store them in an event log.

Demo: http://is.gd/qcBhbH

[nikomatsakis]

Oh dear. ☔