Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DST coercions are prevented by phantom data #26905

Closed
Gankro opened this Issue Jul 8, 2015 · 4 comments

Comments

Projects
None yet
4 participants
@Gankro
Copy link
Contributor

Gankro commented Jul 8, 2015

This prevents Rc from having a sound definition with respect to dropcheck

#![feature(unsize, coerce_unsized)]

use std::marker::{Unsize, PhantomData};
use std::ops::CoerceUnsized;

struct MyRc<T: ?Sized> {
    ptr: *const T,
    _boo: PhantomData<T>,
}

impl<T: ?Sized + Unsize<U>, U: ?Sized> CoerceUnsized<MyRc<U>> for MyRc<T>{ }

fn main() {}
<anon>:11:1: 11:77 error: the trait `CoerceUnsized` may only be implemented for a coercion between structures with one field being coerced, but 2 fields need coercions: ptr (*const T to *const U), _boo (core::marker::PhantomData<T> to core::marker::PhantomData<U>) [E0375]
<anon>:11 impl<T: ?Sized + Unsize<U>, U: ?Sized> CoerceUnsized<MyRc<U>> for MyRc<T>{ }
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error

@Gankro Gankro added the P-high label Jul 8, 2015

@Gankro

This comment has been minimized.

Copy link
Contributor Author

Gankro commented Jul 8, 2015

@Gankro Gankro added the A-dst label Jul 8, 2015

@nrc

This comment has been minimized.

Copy link
Member

nrc commented Jul 9, 2015

I think DST coercions should just ignore all zero-sized fields

@eddyb

This comment has been minimized.

Copy link
Member

eddyb commented Jul 9, 2015

@nrc the only immediate solution would be ignoring PhantomData. Actually, that's still problematic.
I guess would could ignore PhantomData<T> -> PhantomData<U> where T: Unsize<U>.
Otherwise, it's possible to construct a type where coercing can modify its properties in an incompatible way.
Although, could it lead to memory safety, if no unsafe code is used with it?

@arielb1

This comment has been minimized.

Copy link
Contributor

arielb1 commented Jul 9, 2015

@eddyb

I don't think PhantomData serves as a witness today (and you have to implement Unsize for this to be important).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.