std::rc::Rc should accept DST

[little-arhat]

It's currently impossible to store DST (Trait object, for example) inside RC:

let x:std::rc::Rc<Reader>;

gives you: the trait 'core::kinds::Sized' must be implemented because it is required by 'alloc::rc::Rc'. However, you can store trait object inside Box. Rc uses Box internally, so it seems inconsistent that one cannot use refcounted box as replacement for Box.

One could work around this issue by storing Box<Trait> inside Rc, but that would incur double indirection.

Moreover, one couldn't implement their own Rc because of related ICE: #17959 .

(Maybe related to: #16918 )

[brandonson]

No idea whether we even want to change things before #16918 gets resolved, but I'll work on this just to give me an excuse to dig into the libs again.

[little-arhat]

@brandonson FYI, I've tried to fix it by changing RcBox to:

struct RcBox<Sized? T> {
    strong: Cell<uint>,
    weak: Cell<uint>,
    value T
}

but that didn't work out because of ICE from #17959 .

[brandonson]

Quick update, my attempts have halted for the moment. The way I did it appears to have made compiling std cause rustc to enter an infinite loop, and I had added an extra pointer in any case. We may just want to wait for that ICE to be fixed.

[steveklabnik]

This also impacts using closures, since they're trait objects.

[milibopp]

Shouldn't this include std::sync::Arc? Or would that be a separate PR?

[steveklabnik]

It could be the same, the root cause is the same.

[nrc]

There are two pieces missing here: we need coercions of deeply DST objects in order to create Rc<T> and we need to handle drop - the latter uses a bunch of functions, mainly size_of which don't accept ?Sized type params. The rest is just adding ?Sized in a bunch of places (which I have on a branch).

I'm working on spec'ing then implementing the DST coercions atm. I guess #19063 will cover everything that needs doing to implement drop, but I haven't checked that.

Arc has exactly the same issues as Rc (drop and coercions).

[japaric]

FWIW, I have an out of tree implementation of Rc that works with DST. I've mainly tested Rc<str> and Rc<Fn(A, B) -> C> and valgrind seems to be happy with it.

My implementation only supports strong references [1] and uses a different data layout than the one in libstd, which results in a simple implementation of the constructor and the destructor. I have also documented the (re)allocations that each constructor/conversion (e.g. String -> Rc<str>) may require.

[1] I didn't implement weak references because (I think) I don't need them (yet) for what I'm using the Rc for (I don't have to deal with cyclic structures, or have RefCells in my code which AFAIK are required to create them)

[huonw]

@japaric cool! Although, fwiw, that sort of pointer (with separate allocation for the refcounts) almost exists today via Rc<Box<T>>.

[japaric]

that sort of pointer (with separate allocation for the refcounts) almost exists today via Rc<Box>.

Yes, but that one has double indirection, it's like Box<Box<Trait>> and Box<String>. Each call to deref has to go through one layer of indirection.

[huonw]

Yeah, hence "almost". :)