Repository navigation
CoercePointee doesn't tightly enforce the restriction to #[repr(transparent)]-only wrappers, if other proc-macros are involved #135206
Description
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
Reacted by wieDasDing
Activity
[-]`CoercePointee` doesn't effectively enforce the restriction to `#[repr(transparent)]`-only wrappers[/-][+]`CoercePointee` doesn't tightly enforce the restriction to `#[repr(transparent)]`-only wrappers, if other proc-macros are involved[/+]dingxiangfei2009 commentedon Jan 15, 2025
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 ...CoercePointeeWellformed, likeAsyncFnKindHelper. Name subject to scrutinee.derive(CoercePointee), we add aimpl<..> CoercePointeeWellformed for ...impl<..> CoercePointeeWellformed for ... For this issue, it will check the field and shape of theSelftype in perspectiveimpls.Apologies ahead for using wrong terms and please don't hesitate to correct me.
cc @Darksonn
steffahn commentedon Jan 15, 2025
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 commentedon Jan 16, 2025
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
CoercePointeeWellFormedtrait? If so, then it sounds like there's an opportunity to use the same trait for both checks.dingxiangfei2009 commentedon Jan 21, 2025
I am experimenting the WF trait since this week. I will report back with results.
@rustbot claim
Rollup merge of rust-lang#136107 - dingxiangfei2009:coerce-pointee-we…
Rollup merge of rust-lang#136107 - dingxiangfei2009:coerce-pointee-we…
Rollup merge of rust-lang#136107 - dingxiangfei2009:coerce-pointee-we…
Unrolled build for rust-lang#136107
Rollup merge of rust-lang#136107 - dingxiangfei2009:coerce-pointee-we…
Rollup merge of rust-lang#136107 - dingxiangfei2009:coerce-pointee-we…