src/test/incremental/reorder_vtable.rs


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

// revisions:rpass1 rpass2

// This test case makes sure re-order the methods in a vtable will
// trigger recompilation of codegen units that instantiate it.
//
// See https://github.com/rust-lang/rust/issues/89598

trait Foo {
    #[cfg(rpass1)]
    fn method1(&self) -> u32;

    fn method2(&self) -> u32;

    #[cfg(rpass2)]
    fn method1(&self) -> u32;
}

impl Foo for u32 {
    fn method1(&self) -> u32 { 17 }
    fn method2(&self) -> u32 { 42 }
}

fn main() {
    // Before #89598 was fixed, the vtable allocation would be cached during
    // a MIR optimization pass and then the codegen pass for the main object
    // file would not register a dependency on it (because of the missing
    // dep-tracking).
    //
    // In the rpass2 session, the main object file would not be re-compiled,
    // thus the mod1::foo(x) call would pass in an outdated vtable, while the
    // mod1 object would expect the new, re-ordered vtable, resulting in a
    // call to the wrong method.
    let x: &dyn Foo = &0u32;
    assert_eq!(mod1::foo(x), 17);
}

mod mod1 {
    pub(super) fn foo(x: &dyn super::Foo) -> u32 {
        x.method1()
    }
}