Adding upstream version 1.64.0+dfsg1.upstream/1.64.0+dfsg1

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 41 insertions, 0 deletions

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()
+    }
+}