`CoercePointee` doesn't tightly enforce the restriction to `#[repr(transparent)]`-only wrappers, if other proc-macros are involved

[steffahn]

Define a proc macro that strips the #[repr(transparent)].

#[proc_macro_attribute]
pub fn untransparent(_: TokenStream, item: TokenStream) -> TokenStream {
    let mut i = item.into_iter();
    drop(i.next());
    drop(i.next());
    i.collect()
}

use it

#![feature(derive_coerce_pointee)]
use std::marker::CoercePointee;
use …:untransparent;

#[derive(CoercePointee)]
#[untransparent]
#[repr(transparent)]
struct Foo<T: ?Sized>(Box<T>);

---

compiles successfully, expands to

#![feature(prelude_import)]
#![feature(derive_coerce_pointee)]
#[prelude_import]
use std::prelude::rust_2021::*;
#[macro_use]
extern crate std;
use std::marker::CoercePointee;
use …::untransparent;
struct Foo<T: ?Sized>(Box<T>);
#[automatically_derived]
impl<
    T: ?Sized + ::core::marker::Unsize<__S>,
    __S: ?Sized,
> ::core::ops::DispatchFromDyn<Foo<__S>> for Foo<T> {}
#[automatically_derived]
impl<
    T: ?Sized + ::core::marker::Unsize<__S>,
    __S: ?Sized,
> ::core::ops::CoerceUnsized<Foo<__S>> for Foo<T> {}

As far as I understand the RFC and intent, the intended stabilization should only stabilize allowing these (CoerceUnsized & DispatchFromDyn impls) to be generated for #[repr(transparent)] types.

@rustbot label F-derive_coerce_pointee

[dingxiangfei2009]

Hey @steffahn and @BoxyUwU ! Thanks for spotting this!

I was thinking the other day. Would it make sense that we enforce the repr(transparent) on the HIR typeck stage? I imagine that ...

1. we could introduce a concrete but hidden trait CoercePointeeWellformed, like AsyncFnKindHelper. Name subject to scrutinee.
2. in derive(CoercePointee), we add a impl<..> CoercePointeeWellformed for ...
3. while checking coherence, we check validity of each impl<..> CoercePointeeWellformed for ... For this issue, it will check the field and shape of the Self type in perspective impls.

Apologies ahead for using wrong terms and please don't hesitate to correct me.

cc @Darksonn

[steffahn]

My ”dumb idea“ personally here would be: could validation of the DispatchFromDyn (the code that already makes sure that there’s only a single non-ZST field – recently upgraded to single non-PhantomData) impl simply also enforce the #[repr(transparent)] (on the struct) if there’s #[automatically_derived] on it (on the impl)?

[Darksonn]

Checking #[automatically_derived] sounds like it would take fewer lines of code, but it also sounds more hacky, so I'm not sure it's the best approach.

@compiler-errors In the fix you wanted to make for #135217, are you planning to introduce a new CoercePointeeWellFormed trait? If so, then it sounds like there's an opportunity to use the same trait for both checks.

[dingxiangfei2009]

I am experimenting the WF trait since this week. I will report back with results.

@rustbot claim