Allow transmutes between the same types after erasing lifetimes

[oli-obk]

r? @compiler-errors on the impl

fixes #101081

See discussion in the issue and at https://rust-lang.zulipchat.com/#narrow/stream/326866-t-types.2Fnominated/topic/.23101081.3A.20Regression.20transmuting.20.60RwLockReadGuard.3CT.3A.20.3FSized.3E.E2.80.A6

I think this may need lang team signoff as its implications may go beyond the jurisdiction of T-types

I'll write up a proper summary later

[compiler-errors]

r=me on the implementation, waiting for FCP

[apiraino]

Signaling the above comment with a S-blocked label

@rustbot label s-blocked

[oli-obk]

transmuting between (generic) types is only allowed for specific subsets of types. Usually this means that you can transmute between types where the sizes are known (e.g. pointers) or structs of a single field of such a type.

The problem with those rules is that you can easily end up in a situation where transmute<Foo<'a, T>, Foo<'b, T>>(x) is rejected, because there are some non-zst fields:

struct Foo<'a, T: ?Sized>(&'a T, i32);

fn foo<'a, 'b, T: ?Sized>(x: Foo<'a, T>) -> Foo<'b, T> {
    unsafe { std::mem::transmute(x) }
    // ^ only an error if the `i32` field is there, otherwise compiles fine
}

I propose to relax the rules on transmutes and allow transmutes between types that are equal (ignoring regions). This means we lock ourselves into a world where we can never use specialization on lifetimes to change types. As far as I can tell this would be unsound for other reasons anyway, so it's not a loss.

@rfcbot merge

[rfcbot]

Team member @oli-obk has proposed to merge this. The next step is review by the rest of the tagged team members:

• @compiler-errors
• @cramertj
• @jackh726
• @joshtriplett
• @lcnr
• @nikomatsakis
• @oli-obk
• @pnkfelix
• @scottmcm
• @spastorino

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[joshtriplett]

The only lifetime I can imagine specializing on would be 'static. Would that still be an option, potentially?

[lcnr]

Specialization (affecting associated typesthe type system, so either assoc types/consts or const functions) being possible based on 'static is in conflict with this PR. However, specialization based on 'static is already impossible (or nearly so) due to other reasons:

Const evaluation has to happen during typeck for const generics. During typeck we do not know whether some arbitrary region variable will end up as 'static. If a constant therefore references some region variable, we can only evaluate that one once borrowck is complete. We need to evaluate constants before borrowck however.

We also ignore regions in other areas of the compiler which might be slightly easier to change (if still difficult).

But even ignoring the difficulty of actually implementing specialization based on 'static, I don't think we should add that for 2 reasons:

borrowck is currently only a safety check, it does not impact codegen in any way. This is a nice property we lose this way.

It is also quite difficult to understand where lifetimes are actually 'static. Promotion makes things 'static which shouldn't be while subtyping "un-'statics" things which should be 'static. e.g. consider fn two_inputs<'a>(a: &'a (), b: &'a ()). If you call that function with 'static and some shorter local lifetime, subtyping changes 'static to the shorter lifetime, which would change the impl used by specialization at some point in the call graph, which is really bad.

[nikomatsakis]

@rfcbot reviewed

[scottmcm]

Pondering: Does adding this make it any harder in (the far) future to change the check from being compiler-magic to some kind of where const { size_of::<T>() == size_of::<U>() }? Or are there already existing cases that make the complicated (other than the questions about how to add such constraints at all).

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[lcnr]

Pondering: Does adding this make it any harder in (the far) future to change the check from being compiler-magic to some kind of where const { size_of::<T>() == size_of::<U>() }? Or are there already existing cases that make the complicated (other than the questions about how to add such constraints at all).

wouldn't expect so, ctfe also erases regions, so this shouldn't add any additional complications.

[bors]

☔ The latest upstream changes (presumably #102068) made this pull request unmergeable. Please resolve the merge conflicts.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[compiler-errors]

r=me when rebased

[oli-obk]

@bors r=compiler-errors

[bors]

📌 Commit d90d055 has been approved by compiler-errors

It is now in the queue for this repository.