Trait object types aren’t enforcing equality constraints on associated types of super-traits

[steffahn]

Found in #57893 (comment)

trait SuperTrait {
    type A;
    type B;
}

trait Trait: SuperTrait<A = <Self as SuperTrait>::B> {}

fn transmute<A, B>(x: A) -> B {
    // why does rustc not complain about
    // the type `dyn Trait<A = A, B = B>` ?!?
    foo::<A, B, dyn Trait<A = A, B = B>>(x)
}

fn foo<A, B, T: ?Sized>(x: T::A) -> B
where
    T: Trait<B = B>,
{
    x
}

static X: u8 = 0;
fn main() {
    let x = transmute::<&u8, &[u8; 1_000_000]>(&X);
    println!("{:?}", x[100_000]);
}

(Playground)

Errors:

   Compiling playground v0.0.1 (/playground)
    Finished dev [unoptimized + debuginfo] target(s) in 1.13s
     Running `target/debug/playground`
timeout: the monitored command dumped core
/playground/tools/entrypoint.sh: line 11:     7 Segmentation fault      timeout --signal=KILL ${timeout} "$@"

@rustbot modify labels: T-compiler, C-bug, A-traits, A-dst, A-associated-items, A-typesystem
and please add “I-unsound 💥”

[Aaron1011]

cc @matthewjasper - this looks like it might be related to some of your work.

[apiraino]

Assigning P-high as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

[steffahn]

Without the dyn keyword, the transmute function type-checks since Rust 1.0.0. And a main function like e.g.

static X: u8 = 123;
fn main() {
    let x = vec![None::<&[u8]>];
    let r = transmute::<&Option<&[u8]>, &Option<&[u8]>>(&x[0]);
    drop(x);
    let _x = vec![&X as *const _ as usize, 1000000];
    println!("{:?}", r.unwrap());
}

leads to reading a bunch of memory and segfaulting on every Rust version, as far as I can tell (at least in debug builds).

[scalexm]

To me, this is the same root cause as #44454: we unconditionally say that any dyn Trait type is well-formed and implements Trait without checking the actual where clauses declared on the trait, so you can deduce contradictory things with the help of implied bounds (to be fair, #73905 already introduced some checks).

Except that I was wrong in my comment saying that an easy fix for our current limited form of implied bounds would be to just check transitive lifetime requirements. Obviously, @steffahn’s example shows that implied bounds for super traits play a role as well.