Make std::fs::{File, ReadDir, DirEntry} always needs_drop even when unsupported. - #162444
Make std::fs::{File, ReadDir, DirEntry} always needs_drop even when unsupported.#162444kpreid wants to merge 1 commit into
std::fs::{File, ReadDir, DirEntry} always needs_drop even when unsupported.#162444Conversation
always needs_drop` even when unsupported.std::fs::{File, ReadDir, DirEntry} always needs_drop even when unsupported.
…en unsupported. This eliminates the portability hazard (and inconsistent linting of `clippy::drop_non_drop`) of types having destructors on some platforms and not others. It is arguably a breaking change, but a breaking change that would also be required if any of these platforms later gains filesystem support. An alternative to this change would be to implement `Drop` on the `std::fs` types instead of the `std::sys` types. That would be more reliable, but would be more of a public API change since `T: Drop` bounds are unfortunately possible.
|
r? @clarfonthey rustbot has assigned @clarfonthey. Use Why was this reviewer chosen?The reviewer was selected based on:
|
I'd argue that this isn't breaking, @bors r+ rollup |
I was imprecise and meant all the effects of "has a destructor" rather than literally pub const fn foo(file: std::fs::File) {} |
|
Oh, right, non- @bors r- I thought this was trivial, but it isn't. |
|
This pull request was unapproved. |
|
Crater can't tell us the impact of this change, since crater only builds for linux... |
|
Yeah, feel like this would be best with some more discussion, although we're potentially not meeting for another 1-2 weeks, so, maybe it might be worth opening a Zulip thread. |
|
@Mark-Simulacrum has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
This eliminates the portability hazard (and inconsistent linting of
clippy::drop_non_drop) of types having destructors on some platforms and not others.It is arguably a breaking change, but a breaking change that would also be required if any of these platforms later gains filesystem support.
An alternative to this change would be to implement
Dropon thestd::fstypes instead of thestd::systypes. That would be more reliable, but would be more of a public API change sinceT: Dropbounds are unfortunately possible.