Skip to content

Make std::fs::{File, ReadDir, DirEntry} always needs_drop even when unsupported. - #162444

Open
kpreid wants to merge 1 commit into
rust-lang:mainfrom
kpreid:filedrop
Open

Make std::fs::{File, ReadDir, DirEntry} always needs_drop even when unsupported.#162444
kpreid wants to merge 1 commit into
rust-lang:mainfrom
kpreid:filedrop

Conversation

@kpreid

@kpreid kpreid commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

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.

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Sep 7, 2026
@kpreid kpreid changed the title Make std::fs::{File, ReadDir, DirEntry} always needs_drop` even when unsupported. Make std::fs::{File, ReadDir, DirEntry} always needs_drop even when unsupported. Sep 7, 2026
…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.
@kpreid
kpreid marked this pull request as ready for review September 7, 2026 20:08
@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 7, 2026
@rustbot rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Sep 7, 2026
@rustbot

rustbot commented Sep 7, 2026

Copy link
Copy Markdown
Collaborator

r? @clarfonthey

rustbot has assigned @clarfonthey.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: @ChrisDenton, libs
  • @ChrisDenton, libs expanded to 13 candidates
  • Random selection from ChrisDenton, Darksonn, JohnTitor, Mark-Simulacrum, clarfonthey

@joboet

joboet commented Sep 7, 2026

Copy link
Copy Markdown
Member

It is arguably a breaking change, but a breaking change that would also be required if any of these platforms later gains filesystem support.

I'd argue that this isn't breaking, needs_drop doesn't promise anything except for a lack of false-negatives, so a change to a positive is fine – especially since this improves consistency.

@bors r+ rollup
r? joboet

@rust-bors

rust-bors Bot commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

📌 Commit ae174cf has been approved by joboet

It is now in the queue for this repository.

@rust-bors rust-bors Bot added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Sep 7, 2026
@rust-bors rust-bors Bot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 7, 2026
@kpreid

kpreid commented Sep 7, 2026

Copy link
Copy Markdown
Contributor Author

It is arguably a breaking change, but a breaking change that would also be required if any of these platforms later gains filesystem support.

I'd argue that this isn't breaking, needs_drop doesn't promise anything except for a lack of false-negatives, so a change to a positive is fine – especially since this improves consistency.

I was imprecise and meant all the effects of "has a destructor" rather than literally needs_drop alone. For example, this PR will make the following program stop compiling on wasm32-unknown-unknown:

pub const fn foo(file: std::fs::File) {}

@joboet

joboet commented Sep 7, 2026

Copy link
Copy Markdown
Member

Oh, right, non-const Drop is a thing...

@bors r-

I thought this was trivial, but it isn't.

@rust-bors rust-bors Bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Sep 7, 2026
@rust-bors

rust-bors Bot commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

This pull request was unapproved.

View changes since this unapproval

@joboet joboet added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 7, 2026
@theemathas theemathas added needs-crater This change needs a crater run to check for possible breakage in the ecosystem. and removed needs-crater This change needs a crater run to check for possible breakage in the ecosystem. labels Sep 8, 2026
@theemathas

Copy link
Copy Markdown
Contributor

Crater can't tell us the impact of this change, since crater only builds for linux...

@clarfonthey

Copy link
Copy Markdown
Contributor

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

Mark-Simulacrum commented Sep 8, 2026

Copy link
Copy Markdown
Member

We've done this in the past for other, similarly shaped, changes -- e.g., #155113, #155153. I think we should do this here too.

@rfcbot fcp merge libs

@rust-rfcbot

rust-rfcbot commented Sep 8, 2026

Copy link
Copy Markdown
Collaborator

@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.

@rust-rfcbot rust-rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Sep 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants