Associated type constraints on super traits allowing for unsound transmutation to trait objects

[Kyykek]

This code allows for unsound transmutation to trait objects of trait with impossible constraints.

trait TypeEq {
    type This: ?Sized;
}

impl<T: ?Sized> TypeEq for T {
    type This = T;
}

fn identity<T: ?Sized>(t: &<T as TypeEq>::This) -> &T {
    t  // T::This is deduced to be T
}

trait Cat {
    fn meow(&self) {
        println!("meow");
    }
}

struct SomeType;
impl Cat for SomeType {}

// `dyn Dog` isn't a valid type, but we are still allowed to create a trait object of this
trait Dog: TypeEq<This = dyn Cat> {
    fn bark(&self) {
        println!("bark");
    }
}

pub fn main() {
    let normal_coercion: &dyn Cat = &SomeType;

    // `T` is inferred to be `dyn Dog`, `T::This` is inferred as `dyn Cat`, which is different from how the compiler
	// inferred these types in the function definition.
    let oh_no_my_vtable: &dyn Dog = identity(normal_coercion);

    oh_no_my_vtable.bark(); // meow :3
}

I'm not sure if this is a special case of one of the numerous similar known bugs, so I thought I should share it just in case. Simpler cases where the types' memory layouts do not match cause the compiler to panic or llvm to segfault during optimization.

[asquared31415]

A trivial change allows a segfault in safe code:

trait Dog: TypeEq<This = dyn Cat> {
    fn bark(&self) {
        println!("bark");
    }

    fn extra(&self) {
        panic!("extra");
    }
}

// ... 

oh_no_my_vtable.extra(); // segfault

[Kyykek]

Note that that code does not segfault with rustc 1.71; it simply does nothing. 1.70 compiles it to a segfault.
Both 1.71 and 1.70 compile to a SIGILL when turning on optimizations (-O).

Compiler Explorer

[Kyykek]

Here is the compiler panic example (presumably caused by the transmutation of a thin pointer to a fat pointer)

trait TypeEq {
    type This: ?Sized;
}

impl<T: ?Sized> TypeEq for T {
    type This = Self;
}

fn identity<T: ?Sized>(t: &<T as TypeEq>::This) -> &T {
    t
}

struct SomeType;

// compiler crashes if called
fn unsound(x: &SomeType) -> &dyn TypeEq<This = SomeType> {
    identity(x)
}

fn main() {
    let thing = SomeType;
    unsound(&thing);  // crash!
}

Compiler Explorer

Here is the example that causes a libLLVM segfault when using -O

trait TypeEq {
    type This: ?Sized;
}

impl<T: ?Sized> TypeEq for T {
    type This = Self;
}

fn identity<T: ?Sized>(t: &<T as TypeEq>::This) -> &T {
    t
}

trait Dog: TypeEq<This = [u8]> {
    fn woof(&self) {
        println!("woof");
    }
}

fn main() {
    let arr = vec![1; 0];
    let arr: &[u8] = &arr; // fat pointer (ptr, len) with len being 0
    let dog: &dyn Dog = identity(arr);  // (data_ptr, vtable_ptr) with vtable_ptr having address 0 
	// (at least this is what i assume, idk how DSTs are actually 
	// represented when turned into trait objects) 
    dog.woof(); // llvm does not like this.
}

Compiler Explorer

Replacing vec![1; 0] with Vec::new() or just [1; 0] causes the output program to segfault instead. There seems to be some weird stuff going on when adding in the complexity of std::vec::from_elem() (the doc hidden function called by vec! in this case).
The segfault also happened when i first came across this while writing type level magic. The compiler just segfaulting on me without any sort of error message initially made me think that I had screwed up something with my environment.

[fmease]

@rustbot label -needs-triage T-compiler T-types I-unsound A-trait-objects A-associated-items A-coercions

[Kyykek]

This is very similar to #57893, in that an incorrect associated type bound is assumed correct.