Skip PhantomData in Unsize checks

[dingxiangfei2009]

This does not fix #148727, rather probably a good addition to how Unsize behaves. I am looking into anti-fundamenetal trait as suggested to solve a different problem.

This patch proposes relaxation on the type unsizing condition.
PhantomData has been in the current type system exempted from being treated as carrying any data, including dropck, virtual call dispatch by DispatchFromDyn and unsizing container by CoerceUnsize. PhantomData is a special 1-ZST that really carries no "data" of the types it captures.

I propose that we should also extend this interpretation to Unsize.

[rustbot]

r? @lcnr

rustbot has assigned @lcnr.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[theemathas]

FYI, with the way you currently worded this PR, if it were to be merged, #148727 would be closed.

[theemathas]

This change is visible on stable. The following code fails to compile on nightly, but compiles with this PR

use std::marker::PhantomData;

pub struct Thing<T: ?Sized>(PhantomData<T>, T);

pub fn foo(x: &Thing<i32>) -> &Thing<dyn Send> {
    x
}

I'm unsure whether this code starting to compiling might cause some library to become unsound.

[lcnr]

seems fine from a @rust-lang/types perspective, would like to hand this over to lang.

Is there a specific use enabled by this/what's the reasoning behind this PR?

Right now my vibe here is "sure, would be fine, don't really see why this is relevant" which probably makes it harder for T-lang to make a decision here,

The start of the PR description is a bit confusing 😅

This does not fix #148727, rather probably a good addition to how Unsize behaves. I am looking into anti-fundamenetal trait as suggested to solve a different problem.

While you're explicitly stating that it does not fix #148727, this is the first thing you mention so I end up thinking "hmm, how does this relate to #148727, do I have to understand that issue to review this".

I think this PR literally doesn't interact with that unsoundness, so either don't mention it at all or as a quick note at the end stating that these this PR does not interact with it