transmutability: unexpected behaviour when both init and uninit transitions are present

[tmiasko]

#![feature(transmutability)]
use std::mem::{Assume, MaybeUninit, TransmuteFrom};

pub fn is_transmutable<Src, Dst>() where Dst: TransmuteFrom<Src, { Assume::SAFETY }>{}

#[derive(Copy, Clone)]
#[repr(u8)]
enum B0 { Value = 0 }

#[derive(Copy, Clone)]
#[repr(u8)]
enum B1 { Value = 1 }

fn main() {
    is_transmutable::<(B0, B0), MaybeUninit<(B0, B0)>>(); // ok
    is_transmutable::<(B0, B0), MaybeUninit<(B0, B1)>>(); // unexpected error: `(B0, B0)` cannot be safely transmuted into `MaybeUninit<(B0, B1)>`
    is_transmutable::<(B0, B0), MaybeUninit<(B1, B0)>>(); // ok
    is_transmutable::<(B0, B0), MaybeUninit<(B1, B1)>>(); // ok
}

cc @jswrenn

[tmiasko]

Currently an uninit transition matches both an uninit byte and all values in
[0..255]. When both kinds of transitions are present in a state, an automaton
becomes non-deterministic.

I was thinking about addressing this by changing uninit transition to match
uninit byte only, while at the same time generating complete set of edges for
Tree::uninit.

[jswrenn]

Our union support has some potential soundness holes, since the validity rules of unions aren't fully decided. See here for a description of the issue and the solution we'd like to work towards: rust-lang/project-safe-transmute#19

That aside, the issue you've found is very weird and we should fix it. There's no good reason those two middle tests should behave differently, and I don't yet follow why that would be the case.