Turn tcx.vtable_allocation() into a query.

1 files changed, 15 insertions, 1 deletions

diff --git a/src/test/incremental/reorder_vtable.rs b/src/test/incremental/reorder_vtable.rs
index a550fe6f01c..8dacba63351 100644
--- a/src/test/incremental/reorder_vtable.rs
+++ b/src/test/incremental/reorder_vtable.rs
@@ -1,5 +1,10 @@
 // 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;
@@ -16,12 +21,21 @@ impl Foo for u32 {
 }
 
 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 fn foo(x: &dyn super::Foo) -> u32 {
+    pub(super) fn foo(x: &dyn super::Foo) -> u32 {
         x.method1()
     }
 }