Change lint message to be stronger for &T -> &mut T transmute

[5225225]

The old message implied that it's only UB if you use the reference to mutate, which (as far as I know) is not true. As in, the following program has UB, and a &T -> &mut T transmute is effectively an unreachable_unchecked.

fn main() {
    #[allow(mutable_transmutes)]
    unsafe {
        let _ = std::mem::transmute::<&i32, &mut i32>(&0);
    }
}

In the future, it might be a good idea to use the edition system to make this a hard error, since I don't think it is ever defined behaviour? Unless we rule that &UnsafeCell<i32> -> &mut i32 is fine. (That, and you always could just use .get(), so you're not losing anything)

[rust-highfive]

r? @michaelwoerister

(rust-highfive has picked a reviewer for you, use r? to override)

[chorman0773]

I also wonder if this can't be promoted to a forbid-by-default, though perhaps that should be a separate PR that gets a crater run.

[michaelwoerister]

Thanks for the PR, @5225225!

According to the "Producing an invalid value, even in private fields and locals." in the reference this sounds correct to me.

I'll ping @RalfJung to give his opinion before r+ing though.

[RalfJung]

Under Stacked Borrows this transmute is indeed insta-UB, but future models might be able to fix rust-lang/unsafe-code-guidelines#133 and then the transmute could actually be okay, and only actual mutation would be problematic.

[michaelwoerister]

Thanks for the info, @RalfJung!

Let's make the message stricter for now.

@bors r+ rollup

[bors]

📌 Commit 36a1141 has been approved by michaelwoerister

[RalfJung]

Hm, not sure I agree with that decision -- so far we have avoided making any official statements based on Stacked Borrows.

The reality is that the rules of what exactly is and is not allowed here simply have not been decided yet. So this transmute is better avoided but the lint is a bit too definite in its statement IMO.