Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dropck doc oversights / revision #29111

Open
pnkfelix opened this issue Oct 16, 2015 · 7 comments
Open

dropck doc oversights / revision #29111

pnkfelix opened this issue Oct 16, 2015 · 7 comments
Assignees
Labels
A-destructors Area: Destructors (`Drop`, …) C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@pnkfelix
Copy link
Member

The implementation of non-parametric dropck (#28861) included comments and doc that is missing a few things.

  1. There was feedback from @gankro on changes to the rustonomicon that should be further tweaks (see comment thread from implement RFC 1238: nonparametric dropck. #28861)
  2. There should be a huge warning (maybe even a lint or something) that if you put #[unsafe_destructor_blind_to_params] on a struct that is using native pointers (e.g. struct Foo<T>( { ptr: *mut T }) then you almost certainly need a PhantomData in there.

The old code before #28861 was in fact busted in this respect, as one can see by taking the test case from #29106 and running it on older versions of Rust.

@pnkfelix pnkfelix self-assigned this Oct 16, 2015
@pnkfelix pnkfelix added the A-destructors Area: Destructors (`Drop`, …) label Oct 16, 2015
@Gankra
Copy link
Contributor

Gankra commented Oct 16, 2015

👍 for a lint; CC @Manishearth

@Manishearth
Copy link
Member

hardwired lint makes sense here.

Note that if you add a lint, you need to be careful about backcompat if you're going to be removing it. We don't have a framework for "obsolete" lints yet, but it could be added.

@steveklabnik
Copy link
Member

Triage: I didn't even know this attribute was a thing!

@apasel422
Copy link
Contributor

@steveklabnik The unsafe_destructor_blind_to_params attribute is deprecated now. CC #34761.

@Mark-Simulacrum
Copy link
Member

@pnkfelix Is there a chance you could comment on the status of this issue since the attribute was deprecated in favor of (other?) issues.

@Mark-Simulacrum Mark-Simulacrum added C-bug Category: This is a bug. C-enhancement Category: An issue proposing an enhancement or a PR with one. and removed C-bug Category: This is a bug. labels Jul 24, 2017
@steveklabnik
Copy link
Member

Triage: with no comment from @pnkfelix, I'm going to consider this stale and close it. felix, please let me know if you think this is still important and we can re-open.

@pnkfelix
Copy link
Member Author

pnkfelix commented Nov 1, 2018

I imagine the same scenario arises with #[may_dangle], which is what replaced unsafe destructor blind to params

@pnkfelix pnkfelix reopened this Nov 1, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-destructors Area: Destructors (`Drop`, …) C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

6 participants