stdlib is instantiating Arc<T> with T's that are not Send+Sync
#23584
Comments
|
(or maybe I can get away with just removing the bounds from the |
|
see also #23176, since it may help remove some of the bounds that we causing us to put these bounds on the |
|
see also rust-lang/rfcs#590, which proposes a coding convention which may have helped us avoid this bug. |
|
Yes this is just a mistake, it's fine to just remove the bounds from the |
|
is this backcompat-libs? |
|
removing the bounds from the 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. |
|
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. |
Reject specialized Drop impls. See Issue rust-lang#8142 for discussion. This makes it illegal for a Drop impl to be more specialized than the original item. So for example, all of the following are now rejected (when they would have been blindly accepted before): ```rust struct S<A> { ... }; impl Drop for S<i8> { ... } // error: specialized to concrete type struct T<'a> { ... }; impl Drop for T<'static> { ... } // error: specialized to concrete region struct U<A> { ... }; impl<A:Clone> Drop for U<A> { ... } // error: added extra type requirement struct V<'a,'b>; impl<'a,'b:a> Drop for V<'a,'b> { ... } // error: added extra region requirement ``` Due to examples like the above, this is a [breaking-change]. (The fix is to either remove the specialization from the `Drop` impl, or to transcribe the requirements into the struct/enum definition; examples of both are shown in the PR's fixed to `libstd`.) ---- This is likely to be the last thing blocking the removal of the `#[unsafe_destructor]` attribute. Fix rust-lang#8142 Fix rust-lang#23584
From arc.rs, we have:
From thread.rs, we have:
And, for completeness, from cell.rs, we have:
This is bad. The
Dropmethod ofArcgets to assume thatTadheres to the stated bounds, butPacketis violating that promise. (The current Rust implementation just blindly emits aDropimpl and invokes it; so presumably the invariants ofArcitself 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
The text was updated successfully, but these errors were encountered: