Repository navigation
Once confident in dropck: remove #[unsafe_destructor] attribute #22196
Description
Spawned off of #8861, this is the last step in RFC #769, Sound Generic Drop.
Basically, once we are relatively confident that:
- the Drop-Check rule is sound,
- the
dropckcode is at least a sound approximation of that rule, and - we have audited APIs in libstd for destructor safety,
then we should remove the #[unsafe_destructor] attribute and all the uses of it.
Activity
pnkfelix commentedon Feb 11, 2015
Nominating; we should decide whether we are going to do this for 1.0 beta, or if it can wait until the 1.0 release itself as a "polish issue." (or if it can wait even beyond that, i.e. to 1.x. But I am not advocating that position.)
(However, given that #21972 just landed today, it may be a good idea to let the code settle for a week before we actually make a decision about this. Its super easy to remove
#[unsafe_destructor], as one can see from the two commits here, its just a matter of having the will to do it. :) )[-]Once confident in Sound Generic Drop: remove `#[unsafe_destructor]` attribute[/-][+]Once confident in dropck: remove `#[unsafe_destructor]` attribute[/+]pnkfelix commentedon Feb 12, 2015
1.0 beta, P-high.
SSheldon commentedon Mar 14, 2015
@pnkfelix, is this still slated for the 1.0 beta?
unsafe_destructoris the last feature my library uses, and I'd love to be able to run it stable on the beta. (Some discussion in #8142 seems to indicate that's a blocker but won't be completed for the beta.)pnkfelix commentedon Mar 20, 2015
@SSheldon I'm going to try, but I don't know if I'll be able to do everything necessary to unfeature gate it by the beta. We will see, I'm reviewing the remaining tasks now.
SSheldon commentedon Mar 20, 2015
@pnkfelix, thanks! For what it's worth, I was able to remove the
unsafe_destructorfeature in my library by moving some of the fields of my struct into a new, non-generic struct and implementingDropon that instead of the generic struct: SSheldon/rust-objc@b2bd3e0. (For anyone else that runs into this, that could potentially be a workaround.)diwic commentedon Mar 23, 2015
If you can't unfeature gate the entire unsafe_destructor, would it be possible to only unfeature gate those Drop impls we're confident with? Like, the simple and obvious ones (for various values of "simple" and "obvious" :-) ). I suspect a majority of Drop impls would be simple and obvious.
pnkfelix commentedon Mar 23, 2015
at this point I have a patch for the main known issue : PR #23638.
An audit of
libstdstill needs to happen, but I would be okay with doing that in between the beta release and 1.0 (and unfeature-gating#[unsafe_destructor]in the meantime. I'll bring it up with the team.Port of pcwalton removal of `#[unsafe_destructor]` check.
Auto merge of #23819 - pnkfelix:kill-unsafe-dtor, r=pnkfelix
Remove `#[unsafe_destructor]`
Merge pull request rust-lang#22196 from ada4a/ada/push-nozlvyxtruwv