stdlib is instantiating `Arc<T>` with T's that are not `Send+Sync`

[pnkfelix]

From arc.rs, we have:

impl<T: Sync + Send> Drop for Arc<T> { ... }

From thread.rs, we have:

struct Packet<T>(Arc<UnsafeCell<Option<Result<T>>>>);

And, for completeness, from cell.rs, we have:

impl<T> !Sync for UnsafeCell<T> {}

This is bad. The Drop method of Arc gets to assume that T adheres to the stated bounds, but Packet is violating that promise. (The current Rust implementation just blindly emits a Drop impl and invokes it; so presumably the invariants of Arc itself are maintained, but the global invariants of the system need not be.)

We have not been checking for this; such a check is the task described in #8142.

But we need to fix this; certainly as long as it is the case, the planned implementation of #8142 cannot land.

cc @alexcrichton @aturon @nikomatsakis

[pnkfelix]

(or maybe I can get away with just removing the bounds from the Drop impl for Arc<T> ...

[pnkfelix]

see also #23176, since it may help remove some of the bounds that we causing us to put these bounds on the Drop impl in the first place.

[pnkfelix]

see also rust-lang/rfcs#590, which proposes a coding convention which may have helped us avoid this bug.

[alexcrichton]

Yes this is just a mistake, it's fine to just remove the bounds from the Drop impl as they're not really needed other than to maybe call a helper method or two (which also don't need the Send+Sync bounds).

[steveklabnik]

is this backcompat-libs?

[pnkfelix]

removing the bounds from the Drop impl for Arc should be a backwards-compatible change.

But there are other cases where the right thing to do is to follow rust-lang/rfcs#590 and put the bounds on the struct/enum definition itself, and those cases would not be backwards-compatible changes.

[pnkfelix]

i am currently thinking I may try to land an incomplete fix for #8142, namely one that accepts some programs that it should reject (namely programs that put outlives-predicates on the Drop implementations without a corresponding bound on the struct/enum definition), just to catch the majority of cases that we expect to encounter and thus limit our exposure to this bug.

[pnkfelix]

actually i got a complete fix for #8142 working; see PR #23638. That PR should resolve this ticket.