From 218caa410aa38c29984be31a5229b9fa717560ee Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Wed, 17 Apr 2024 14:19:13 +0200 Subject: Merging upstream version 1.68.2+dfsg1. Signed-off-by: Daniel Baumann --- src/test/incremental/reorder_vtable.rs | 41 ---------------------------------- 1 file changed, 41 deletions(-) delete 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 deleted file mode 100644 index 8dacba633..000000000 --- a/src/test/incremental/reorder_vtable.rs +++ /dev/null @@ -1,41 +0,0 @@ -// 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