Stabilize most of `io_error_more` #128316

GrigorenkoPV · 2024-07-28T19:10:06Z

Sadly, venting my frustration with t-libs-api is not a constructive way to solve problems and get things done, so I will try to stick to stuff that actually matters here.

Tracking issue for this feature was opened 3 years ago: Tracking Issue for io_error_more #86442
FCP to stabilize it was completed 19(!!) months ago: Tracking Issue for io_error_more #86442 (comment)
A PR with stabilization was similarly open for 19 months: Stabilize io_error_more #106375, but nothing ever came out of it. Presumably (it is hard to judge given the lack of communication) because a few of the variants still had some concerns voiced about them, even after the FCP.

So, to highlight a common sentiment:

Maybe uncontroversial variants can be stabilised first and other variants (such as QuotaExceeded or FilesystemLoop) later? ¹

I would like to voice support stabilization of the uncontroversial variants. This would get those variants to stable and focus the discussion around the more controversial ones. I don't see any particular reason that all of these must be stabilized at the same time. [...] ²

Maybe some less-controversial subset could be stabilized sooner? What’s blocking this issue from making progress? ³

So this is exactly what this PR does. It stabilizes the non-controversial variants now, leaving just a few of them behind.

Namely, this PR stabilizes:

HostUnreachable
NetworkUnreachable
NetworkDown
NotADirectory
IsADirectory
DirectoryNotEmpty
ReadOnlyFilesystem
StaleNetworkFileHandle
StorageFull
NotSeekable
FileTooLarge
ResourceBusy
ExecutableFileBusy
Deadlock
TooManyLinks
ArgumentListTooLong
Unsupported

This PR does not stabilize:

FilesystemLoop
FilesystemQuotaExceeded
CrossesDevices
InvalidFilename

Hopefully, this will allow us to move forward with this highly and long awaited addition to std, both allowing to still polish the less clear parts of it and not leading to stagnation.

r? joshtriplett
because they seem to be listed as a part of t-libs-api and were one of the most responsive persons previously

https://github.com/rust-lang/rust/issues/106375#issuecomment-1435762236 ↩
https://github.com/rust-lang/rust/pull/106375#issuecomment-1742661555 ↩
https://github.com/rust-lang/rust/issues/86442#issuecomment-1691187483 (got 30 upvotes btw) (and no response) ↩

GrigorenkoPV · 2024-08-12T15:53:29Z

r? libs

joboet · 2024-08-12T16:00:44Z

As much as I'd like to help out here, I am not in the libs-api team and should not be the one reviewing this.

r? libs-api

GrigorenkoPV · 2024-08-26T05:45:17Z

r? libs-api

GrigorenkoPV · 2024-09-09T16:20:24Z

r? libs-api

slanterns · 2024-09-09T16:30:51Z

Maybe you can nominate it for T-libs-api discussion.

GrigorenkoPV · 2024-09-09T16:41:03Z

Let's try

@rustbot label +I-libs-api-nominated

Nevermind, it was done while I was writing this. Thank you!

My apologies if I am beeing too pushy with this, it is just that I am worried this PR may suffer the same fate as the previous efforts and fall into indefinite stagnation.

As for re-rolling the reviewers, my reasoning was that if a reviewer is too busy to review this PR, someone else might be less occupied at the moment. Rustbot's default message promises "two weeks for the reviewer to take a look at your PR or pass it to someone else", so that is how long I have waited each time.

dtolnay

Thank you!

I confirmed that all of these variants are covered by the completed libs-api team FCP in #106375 (i.e. none of these are a recent addition) and that neither the tracking issue nor the previous stabilization PR #128316 contains any disagreement applicable to this subset of the variants.

dtolnay · 2024-09-09T20:34:20Z

@bors r+

bors · 2024-09-09T20:34:23Z

📌 Commit f693910 has been approved by dtolnay

It is now in the queue for this repository.

…r=dtolnay Stabilize most of `io_error_more` Sadly, venting my frustration with t-libs-api is not a constructive way to solve problems and get things done, so I will try to stick to stuff that actually matters here. - Tracking issue for this feature was opened 3 years ago: rust-lang#86442 - FCP to stabilize it was completed 19(!!) months ago: rust-lang#86442 (comment) - A PR with stabilization was similarly open for 19 months: rust-lang#106375, but nothing ever came out of it. Presumably (it is hard to judge given the lack of communication) because a few of the variants still had some concerns voiced about them, even after the FCP. So, to highlight a common sentiment: > Maybe uncontroversial variants can be stabilised first and other variants (such as `QuotaExceeded` or `FilesystemLoop`) later? [^1] [^1]: rust-lang#106375 (comment) > I would like to voice support stabilization of the uncontroversial variants. This would get those variants to stable and focus the discussion around the more controversial ones. I don't see any particular reason that all of these must be stabilized at the same time. [...] [^2] [^2]: rust-lang#106375 (comment) > Maybe some less-controversial subset could be stabilized sooner? What’s blocking this issue from making progress? [^3] [^3]: rust-lang#86442 (comment) (got 30 upvotes btw) (and no response) So this is exactly what this PR does. It stabilizes the non-controversial variants now, leaving just a few of them behind. Namely, this PR stabilizes: - `HostUnreachable` - `NetworkUnreachable` - `NetworkDown` - `NotADirectory` - `IsADirectory` - `DirectoryNotEmpty` - `ReadOnlyFilesystem` - `StaleNetworkFileHandle` - `StorageFull` - `NotSeekable` - `FileTooLarge` - `ResourceBusy` - `ExecutableFileBusy` - `Deadlock` - `TooManyLinks` - `ArgumentListTooLong` - `Unsupported` This PR does not stabilize: - `FilesystemLoop` - `FilesystemQuotaExceeded` - `CrossesDevices` - `InvalidFilename` Hopefully, this will allow us to move forward with this highly and long awaited addition to std, both allowing to still polish the less clear parts of it and not leading to stagnation. r? joshtriplett because they seem to be listed as a part of t-libs-api and were one of the most responsive persons previously

…kingjubilee Rollup of 14 pull requests Successful merges: - rust-lang#128316 (Stabilize most of `io_error_more`) - rust-lang#129473 (use `download-ci-llvm=true` in the default compiler config) - rust-lang#129529 (Add test to build crates used by r-a on stable) - rust-lang#129778 (interpret: make typed copies lossy wrt provenance and padding) - rust-lang#129981 (Remove `serialized_bitcode` from `LtoModuleCodegen`.) - rust-lang#130025 (Also emit `missing_docs` lint with `--test` to fulfil expectations) - rust-lang#130040 (unify `llvm-bitcode-linker`, `wasm-component-ld` and llvm-tools logics) - rust-lang#130094 (Inform the solver if evaluation is concurrent) - rust-lang#130132 ([illumos] enable SIGSEGV handler to detect stack overflows) - rust-lang#130146 (bootstrap `naked_asm!` for `compiler-builtins`) - rust-lang#130149 (Helper function for formatting with `LifetimeSuggestionPosition`) - rust-lang#130152 (adapt a test for llvm 20) - rust-lang#130162 (bump download-ci-llvm-stamp) - rust-lang#130164 (move some const fn out of the const_ptr_as_ref feature) r? `@ghost` `@rustbot` modify labels: rollup

…kingjubilee Rollup of 11 pull requests Successful merges: - rust-lang#128316 (Stabilize most of `io_error_more`) - rust-lang#129473 (use `download-ci-llvm=true` in the default compiler config) - rust-lang#129529 (Add test to build crates used by r-a on stable) - rust-lang#129981 (Remove `serialized_bitcode` from `LtoModuleCodegen`.) - rust-lang#130094 (Inform the solver if evaluation is concurrent) - rust-lang#130132 ([illumos] enable SIGSEGV handler to detect stack overflows) - rust-lang#130146 (bootstrap `naked_asm!` for `compiler-builtins`) - rust-lang#130149 (Helper function for formatting with `LifetimeSuggestionPosition`) - rust-lang#130152 (adapt a test for llvm 20) - rust-lang#130162 (bump download-ci-llvm-stamp) - rust-lang#130164 (move some const fn out of the const_ptr_as_ref feature) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of rust-lang#128316 - GrigorenkoPV:io_error_a_bit_more, r=dtolnay Stabilize most of `io_error_more` Sadly, venting my frustration with t-libs-api is not a constructive way to solve problems and get things done, so I will try to stick to stuff that actually matters here. - Tracking issue for this feature was opened 3 years ago: rust-lang#86442 - FCP to stabilize it was completed 19(!!) months ago: rust-lang#86442 (comment) - A PR with stabilization was similarly open for 19 months: rust-lang#106375, but nothing ever came out of it. Presumably (it is hard to judge given the lack of communication) because a few of the variants still had some concerns voiced about them, even after the FCP. So, to highlight a common sentiment: > Maybe uncontroversial variants can be stabilised first and other variants (such as `QuotaExceeded` or `FilesystemLoop`) later? [^1] [^1]: rust-lang#106375 (comment) > I would like to voice support stabilization of the uncontroversial variants. This would get those variants to stable and focus the discussion around the more controversial ones. I don't see any particular reason that all of these must be stabilized at the same time. [...] [^2] [^2]: rust-lang#106375 (comment) > Maybe some less-controversial subset could be stabilized sooner? What’s blocking this issue from making progress? [^3] [^3]: rust-lang#86442 (comment) (got 30 upvotes btw) (and no response) So this is exactly what this PR does. It stabilizes the non-controversial variants now, leaving just a few of them behind. Namely, this PR stabilizes: - `HostUnreachable` - `NetworkUnreachable` - `NetworkDown` - `NotADirectory` - `IsADirectory` - `DirectoryNotEmpty` - `ReadOnlyFilesystem` - `StaleNetworkFileHandle` - `StorageFull` - `NotSeekable` - `FileTooLarge` - `ResourceBusy` - `ExecutableFileBusy` - `Deadlock` - `TooManyLinks` - `ArgumentListTooLong` - `Unsupported` This PR does not stabilize: - `FilesystemLoop` - `FilesystemQuotaExceeded` - `CrossesDevices` - `InvalidFilename` Hopefully, this will allow us to move forward with this highly and long awaited addition to std, both allowing to still polish the less clear parts of it and not leading to stagnation. r? joshtriplett because they seem to be listed as a part of t-libs-api and were one of the most responsive persons previously

rustbot assigned joshtriplett Jul 28, 2024

rustbot added 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. labels Jul 28, 2024

Partially stabilize io_error_more

f693910

GrigorenkoPV force-pushed the io_error_a_bit_more branch from 64814b0 to f693910 Compare July 28, 2024 19:11

GrigorenkoPV changed the title ~~Partially stabilize io_error_more~~ Stabilize most of io_error_more Aug 1, 2024

GrigorenkoPV mentioned this pull request Aug 1, 2024

Also include "Partially stabilize..." releases-rs/releases-rs#27

Open

rustbot assigned joboet and unassigned joshtriplett Aug 12, 2024

rustbot added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Aug 12, 2024

rustbot assigned m-ou-se and unassigned joboet Aug 12, 2024

rustbot assigned BurntSushi and unassigned m-ou-se Aug 26, 2024

Dylan-DPC mentioned this pull request Aug 26, 2024

Tracking Issue for io_error_more #86442

Open

4 tasks

rustbot assigned joshtriplett and unassigned BurntSushi Sep 9, 2024

This comment was marked as resolved.

Sign in to view

rustbot added the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Sep 9, 2024

dtolnay approved these changes Sep 9, 2024

View reviewed changes

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 9, 2024

dtolnay removed the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Sep 9, 2024

dtolnay assigned dtolnay and unassigned joshtriplett Sep 9, 2024

workingjubilee mentioned this pull request Sep 10, 2024

Rollup of 14 pull requests #130177

Closed

workingjubilee mentioned this pull request Sep 10, 2024

Rollup of 11 pull requests #130179

Merged

bors merged commit 1392965 into rust-lang:master Sep 10, 2024
6 checks passed

rustbot added this to the 1.83.0 milestone Sep 10, 2024

GrigorenkoPV deleted the io_error_a_bit_more branch September 10, 2024 10:01

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Stabilize most of `io_error_more` #128316

Stabilize most of `io_error_more` #128316

GrigorenkoPV commented Jul 28, 2024

GrigorenkoPV commented Aug 12, 2024

joboet commented Aug 12, 2024

GrigorenkoPV commented Aug 26, 2024

GrigorenkoPV commented Sep 9, 2024

slanterns commented Sep 9, 2024

This comment was marked as resolved.

GrigorenkoPV commented Sep 9, 2024

dtolnay left a comment

dtolnay commented Sep 9, 2024

bors commented Sep 9, 2024

Stabilize most of io_error_more #128316

Stabilize most of io_error_more #128316

Conversation

GrigorenkoPV commented Jul 28, 2024

Footnotes

GrigorenkoPV commented Aug 12, 2024

joboet commented Aug 12, 2024

GrigorenkoPV commented Aug 26, 2024

GrigorenkoPV commented Sep 9, 2024

slanterns commented Sep 9, 2024

This comment was marked as resolved.

GrigorenkoPV commented Sep 9, 2024

dtolnay left a comment

Choose a reason for hiding this comment

dtolnay commented Sep 9, 2024

bors commented Sep 9, 2024

Stabilize most of `io_error_more` #128316

Stabilize most of `io_error_more` #128316