VTable-related miscompilation with incremental compilation

[michaelwoerister]

PR #86475 introduced a global cache for vtable-layouts into the tcx which circumvents incremental compilation's dependency tracking. The effect is that object files might not get updated when methods within a trait get shuffled around, thus leading to miscompilations very similar to the one observed in #82920, i.e. trait object method calls will invoke the wrong method.

The following test (when added to src/test/incremental) shows this behavior:

// revisions:rpass1 rpass2

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() {
    let x: &dyn Foo = &0u32;
    // This fails in `rpass2` because `method2` gets called instead of `method1`.
    assert_eq!(mod1::foo(x), 17);
}

mod mod1 {
    pub fn foo(x: &dyn super::Foo) -> u32 {
        x.method1()
    }
}

Global caches without dependency tracking are a sure way of introducing subtle incr. comp. bugs. Queries must be used instead.

I'm going to mark this as P-critical. We should fix this asap.

[Aaron1011]

Do we know why this didn't trigger a fingerprint ICE?

[michaelwoerister]

Do we know why this didn't trigger a fingerprint ICE?

Good question! I suspect it is because the changed value never gets fingerprinted anywhere. It is directly used when generating codegen units in the backend and those don't get fingerprinted.

[Mark-Simulacrum]

Milestoning at 1.56. #86475 landed into 1.55, but we should try to fix this as soon as possible on stable as well.