Oibit send and friends

[flaper87]

More work on opt-in built in traits. Send and Sync are not opt-in, OwnedPtr renamed to UniquePtr and the Send and Sync traits are now unsafe.

NOTE: This likely needs to be rebased on top of the yet-to-land snapshot.

r? @nikomatsakis

[breaking-change]

cc #13231

[sfackler]

Can we add a lint or something for "probably wrong" implementations of Sync or Send (i.e. implementations for types that wouldn't be Sync or Send today)? I'm a bit worried with the current setup that it'll be really easy to accidentally mess up and turn a previously safe object into an unsafe object by adding something that's not Sync or Send.

I'm also not really sure why RacyCell exists, unless we add that lint.

[sfackler]

Er, I may have misremembered the OIBIT RFC. The plan is that Sync and Send will still automatically be implemented, you can override a missing impl with unsafe impl Foo and opt out with impl !Foo?

[alexcrichton]

This may not necessarily be a public-facing API that we're willing to commit to at this time, could this be moved into just the std::comm implementation?

[flaper87]

Yup. Actually, @nikomatsakis had asked me to do that already. I haven't done it yet because I didn't quite understand the need. Now I do, thanks for the comment :D

[alexcrichton]

Awesome work! Can't wait for this to land!

[nikomatsakis]

@sfackler Yes, your summary is basically an accurate depiction of the end goal. This RFC does not get all the way there, but it does a big chunk of the work. This RFC doesn't offer a means to explicitly opt out (beyond the marker types that already exist). However, it DOES require an unsafe, explicit opt in if your type contains unsafe pointers (or marker types, but that'd be kind of silly). In a follow-up RFC, we will also make it so that types containing UnsafeCell are not Send or Sync (or at least not Sync, I've been wondering about this) unless they opt in as well. At that point, the opt-in story will be complete. Hopefully we'll get to the explicit opt out (and user-defined .. traits) after that.

[nikomatsakis]

Hmm, so, I think RacyCell can't quite be confined to comm (or rather, we shouldn't bother doing so in this PR), but we should ensure it is not publicly exported from libstd. Otherwise r+ from me.

[flaper87]

@nikomatsakis I believe Mutex and the other types could keep using UnsafeCell since they all implement Sycn. I had replaced UnsafeCell with RacyCell before implementing Sync manually on those types. 2s, brb with a new version ;)

[nikomatsakis]

This looks great! r+ modulo the "DOX" comments

[nikomatsakis]

Giving high priority because this is an important language change, and also somewhat conflict prone.

[tbu-]

You cast it to a Unique and immediately cast it back?

[nikomatsakis]

💯

[shadowmint]

This is a breaking change; please tag it as such.

Any ffi library that was previously using *c_void pointers to have Send wrappers around a c interface (eg. database handle) will be broken after this change.

[shadowmint]

To others who find this, the solution is to manually implement Send boilerplate on your type, as shown in the change log above:

unsafe impl<T: Send + Sync> Send for Foo<T> {}

[flaper87]

@shadowmint note that it's not always required a Send + Sync bound on every implementation of Send. The bounds will depend on the type your implementing Send/Sync for.

As for the broken * pointers, there's a Unique struct that you can use to wrap them. Unique owns the reference to the wrapped value, therefore it's Send and Sync.

For example:

extern crate core;
extern crate libc;

use libc::c_int;
use core::ptr::Unique;

fn test_send<T:Send>(s: T) {}

fn main() {

    let x = Unique(0 as *mut libc::c_int);
    test_send(x);
    // test_send(0 as *mut libc::c_int); // this fails
}