From 698f8c2f01ea549d77d7dc3338a12e04c11057b9 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Wed, 17 Apr 2024 14:02:58 +0200 Subject: Adding upstream version 1.64.0+dfsg1. Signed-off-by: Daniel Baumann --- src/test/incremental/reorder_vtable.rs | 41 ++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 src/test/incremental/reorder_vtable.rs (limited to 'src/test/incremental/reorder_vtable.rs') diff --git a/src/test/incremental/reorder_vtable.rs b/src/test/incremental/reorder_vtable.rs new file mode 100644 index 000000000..8dacba633 --- /dev/null +++ b/src/test/incremental/reorder_vtable.rs @@ -0,0 +1,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() + } +} -- cgit v1.2.3