tests/incremental/reorder_vtable.rs

   1 // revisions:rpass1 rpass2
   2
   3 // This test case makes sure re-order the methods in a vtable will
   4 // trigger recompilation of codegen units that instantiate it.
   5 //
   6 // See https://github.com/rust-lang/rust/issues/89598
   7
   8 trait Foo {
   9     #[cfg(rpass1)]
  10     fn method1(&self) -> u32;
  11
  12     fn method2(&self) -> u32;
  13
  14     #[cfg(rpass2)]
  15     fn method1(&self) -> u32;
  16 }
  17
  18 impl Foo for u32 {
  19     fn method1(&self) -> u32 { 17 }
  20     fn method2(&self) -> u32 { 42 }
  21 }
  22
  23 fn main() {
  24     // Before #89598 was fixed, the vtable allocation would be cached during
  25     // a MIR optimization pass and then the codegen pass for the main object
  26     // file would not register a dependency on it (because of the missing
  27     // dep-tracking).
  28     //
  29     // In the rpass2 session, the main object file would not be re-compiled,
  30     // thus the mod1::foo(x) call would pass in an outdated vtable, while the
  31     // mod1 object would expect the new, re-ordered vtable, resulting in a
  32     // call to the wrong method.
  33     let x: &dyn Foo = &0u32;
  34     assert_eq!(mod1::foo(x), 17);
  35 }
  36
  37 mod mod1 {
  38     pub(super) fn foo(x: &dyn super::Foo) -> u32 {
  39         x.method1()
  40     }
  41 }