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

Tracking Issue for io_error_more #86442

Open
1 of 4 tasks
ijackson opened this issue Jun 18, 2021 · 93 comments
Open
1 of 4 tasks

Tracking Issue for io_error_more #86442

ijackson opened this issue Jun 18, 2021 · 93 comments
Labels
A-error-handling Area: Error handling A-io Area: `std::io`, `std::fs`, `std::net` and `std::path` C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@ijackson
Copy link
Contributor

ijackson commented Jun 18, 2021

Feature gate: #![feature(io_error_more)]

This is a tracking issue for many io::ErrorKind variants being added in #79965.

The additions were motivated by a perusal of Unix standards, but corresponding mappings for Windows were included in that PR.

Public API

std::io::ErrorKind::Foo for many Foo. I will paste a list here when the MR is merged :-).

Steps / History

Unresolved Questions

  • What is our general policy about ErrorKind variants ? It may not be necessary to resolve this wider question in order to stabilise this particular set of ErrorKinds.
@ijackson ijackson added C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jun 18, 2021
@TheBlueMatt
Copy link

What is our general policy about ErrorKind variants ?

Just a bit of user feedback, this PR landing in beta broke our CI as we were asserting certain io Errors. I dunno if you can really call it a "language-breaking" change, but it did seem surprising that our CI would fail on beta due to rust lib changes.

@SimonSapin
Copy link
Contributor

https://doc.rust-lang.org/std/path/struct.Path.html#method.is_dir documents:

This is a convenience function that coerces errors to false. If you want to check errors, call fs::metadata and handle its Result. Then call fs::Metadata::is_dir if it was Ok.

I’ve implemented this by coercing ErrorKind::NotFound to false and propagating other errors. However some of my tests fail in cases where ErrorKind::NotADirectory is (or would be) returned, showing that it should also be coerced to false.

This and the previous comment show that these variants are not like other unstable features that crates who don’t opt-in can pretend don’t exist, they can already be present in errors returned by the standard library. I’d like @rust-lang/libs to consider stabilizing them soon.


@TheBlueMatt, was your code that broke expecting ErrorKind::Other or does this also affect values that previously were, well, other than Other?

@TheBlueMatt
Copy link

TheBlueMatt commented Jul 29, 2021

@TheBlueMatt, was your code that broke expecting ErrorKind::Other or does this also affect values that previously were, well, other than Other?

Yes, it was checking that an error was Other. Still, that seems like a good enough reason that this can't be stabilized as-is? Its not unreasonably that some non-test code could be checking for Other for one reason or another, no?

@joshtriplett
Copy link
Member

@TheBlueMatt Other has been documented for some time as not something you should directly check for:

Errors that are Other now may move to a different or a new ErrorKind variant in the future. It is not recommended to match an error against Other and to expect any additional characteristics, e.g., a specific Error::raw_os_error return value.

#85746 is the change that made the standard library stop returning Other, which was a prerequisite for adding new ErrorKind values.

We do want to stabilize these new variants soon. But in the meantime, if you have code that matches Other and checks a specific underlying error code, you should be able to change that to match _ and check the specific error code.

@TheBlueMatt
Copy link

@TheBlueMatt Other has been documented for some time as not something you should directly check for:

See-also discussion ending at #79965 (comment), but the specific documentation that isn't only lightly implying this being an issue was added middle of last year (which is much more recent than our test code here). Indeed, it was implied earlier, but for those of us who weren't thinking really deeply about the implications of the struct-level docs it didn't come across entirely.

you should be able to change that to match _ and check the specific error code.

Right, we'd have to do even more platform-specific stuff, which I'm a bit hesitant to do, I guess we can just drop our tests, but I do worry about other code that may exist that isn't pure-tests from other projects.

I'm honestly somewhat surprised this is moving forward without some attempts at a rustc warning better communicating to users that the code they have written that compiles and runs is actually undefined behavior (not in the C sense of may-eat-your-cat, but in the may-change-in-the-future, behavior is not guaranteed sense). I understand that may not be practical to hit in all cases, but I imagine at least some direct match .. Other or if == Other things could likely be detected. In general, I am very surprised this doesn't fall under rustc's stability guarantees around running, operational, functional code in the wild not being broken by future versions of rustc.

@ijackson
Copy link
Contributor Author

ijackson commented Jul 29, 2021

Hi, @TheBlueMatt

As the author of one of the MRs which actually broke your test, I would like to say that I'm sorry about that. Unfortunately, risking breakage like yours seemed like the best option. I know it sucks when you're on the wrong side of a tradeoff like this - especially when it suddenly breaks your stuff.

You are right to say that it would have been better to have arranged to warn about this. But doing so in rustc is not currently straightforward. ErrorKind::Other had to be a stable variant, because users of the stdlib need to be able to construct errors with that kind. But we do still need to be able to add variants, rather than having this enum frozen for all time.

Perhaps if we had thought of it sooner, a clippy lint would have made sense. But we didn't have one. (And maybe that wouldn't have helped you; not everyone runs clippy. I know I generally don't, despite feeling guilty about that...)

But given where we were, our sensible options were risking this kind of breakage, or postponing the addition of new ErrorKinds (perhaps for some considerable time) while we did more preparation (eg trying to warn people).

My view is that the new ErrorKinds are very sorely needed. For example, just this week I was writing a program that needs to read configuration from filesystem objects which might be files, or directories. The IsADirectory error from File::open makes that more convenient to do portably and avoids having to ever discard an ErrorKind::Other on the basis of complex reasoning about the filesystem state.

Whether avoiding a substantial delay to new ErrorKinds was worth risking this kind of breakage seems like something reasonable people can disagree on. As others have said, one justification is that the documentation has always said that ErrorKind might grow new variants, and to my mind the implication that those new variants would probably appear instead of Other is obvious. I guess that is cold comfort to you.

Another mitigation is that even when this causes breakage, it is likely to be in tests (as in your case) - ie, the risk of bad code being deployed as a result is considerably lower than that of a test failure.

Having said all that: given this is only in beta, I think we do have the option to back this out ? If we did that, how long would we wait ? Who would write the missing clippy lint or whatever ?

Personally I'm torn. Rust's care for stability is one of its great attractions to me and I regret having undermined that for some of Rust's users. On the other had the previous ErrorKind enum was IMO seriously deficient, and the change in my MR is precisely the kind of change which the docs have always explicitly said may happen (even if all the consequences have only been explicitly spelled out more recently).

I want to reply separately about what alternative idiom I think your tests should probably use.

@joshtriplett
Copy link
Member

joshtriplett commented Jul 29, 2021 via email

@TheBlueMatt
Copy link

TheBlueMatt commented Jul 29, 2021 via email

@joshtriplett
Copy link
Member

@TheBlueMatt Unfortunately, it isn't possible for us to make library changes like this in an edition. Editions can affect how code is compiled, but not the underlying behavior of the standard library, partly because you can have code from Rust 2015, 2018, and 2021 all compiled into one binary and sharing the same standard library.

For what it's worth, we absolutely value stability as critically important. In this case, we made a careful tradeoff, knowing that some code out there (especially test code) might be affected. We did consider making these alternatives insta-stable, but that still would have broken your test case because the enum variant would no longer match. We also considered "never extend ErrorKind again" as a potential alternative, but we felt that because ErrorKind is #[non_exhaustive] and because we don't expect non-test code to typically match on Other in this fashion, we thought it would be reasonably safe to make this change.

One other note: #85746 (which is the change that actually affected your test) is targeted at 1.55, and has a relnotes tag; we're expecting to have a detailed release note explaining the situation for people. A release note does not ameliorate the breakage, but it should help communicate the nature and rationale and tradeoffs of the change.

@TheBlueMatt
Copy link

In this case, we made a careful tradeoff, knowing that some code out there (especially test code) might be affected. We did consider making these alternatives insta-stable, but that still would have broken your test case because the enum variant would no longer match. We also considered "never extend ErrorKind again" as a potential alternative, but we felt that because ErrorKind is #[non_exhaustive] and because we don't expect non-test code to typically match on Other in this fashion, we thought it would be reasonably safe to make this change.

I'm curious if extending the #[non_exhaustive] API in rustc to warn around matching Other variants was considered? eg adding a tag to #[non_exhaustive] to certain variants which indicates "generate a warning if this is matched on or compared against" at compile-time so as to make this exact language pattern better supported. I understand this is maybe part of the goal of #85746, but it does feel like an oversight in the expressiveness of the #[non_exhaustive], as mentioned in the description of #85746.

@ijackson
Copy link
Contributor Author

I'm curious if extending the #[non_exhaustive] API in rustc to warn around matching Other variants was considered? eg adding a tag to #[non_exhaustive] to certain variants ...

No, we didn't think of that.

I understand this is maybe part of the goal of #85746, but it does feel like an oversight in the expressiveness of the #[non_exhaustive], as mentioned in the description of #85746.

Now that #85746 has landed, I don't think this situation can arise again with ErrorKind. In the future, new ErrorKinds may indeed be added, for new kinds of underlying OS errors. But when that happens, the new kind will appear instead of Unknown - not instead of Other. Unknown is permanently unstable so cannot be matched in tests (without turning on an unstable feature). So it would not be possible to write, on stable, a test which will break in the future.

I don't know if there are other enums in the stdlib with similar properties to ErrorKind. I can't think of any offhand.

@TheBlueMatt
Copy link

No, we didn't think of that.

I do wonder if it may make sense as a language feature in the future also for non-stdlib users. It doesn't feel strange to think that some crates may want a similar pattern. I admit the 85746 approach may make more sense to them, but there is no way to non-stabilize a particular enum variant outside of std, as far as I understand.

Unknown is permanently unstable so cannot be matched in tests (without turning on an unstable feature). So it would not be possible to write, on stable, a test which will break in the future.

Ah, maybe I partially misunderstood the way 85746 operates.

TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Aug 2, 2021
std::io::ErrorKind is a `#[non_exhaustive]` enum as more specific
error types are to be added in the future. It was unclear in the
docs until very recently, however, that this is to be done by
re-defining `ErrorKind::Other` errors to new enum variants. Thus,
our tests which check explicitly for `ErrorKind::Other` as a
result of trying to access a directory as a file were incorrect.
Sadly, these generated no meaningful feedback from rustc at all,
except that they're suddenly failing in rustc beta!

After some back-and-forth, it seems rustc is moving forward
breaking existing code in future versions, so we move to the
"correct" check here, which is to check the raw IO error.

See rust-lang/rust#86442 and rust-lang/rust#85746 for more info.
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Aug 2, 2021
std::io::ErrorKind is a `#[non_exhaustive]` enum as more specific
error types are to be added in the future. It was unclear in the
docs until very recently, however, that this is to be done by
re-defining `ErrorKind::Other` errors to new enum variants. Thus,
our tests which check explicitly for `ErrorKind::Other` as a
result of trying to access a directory as a file were incorrect.
Sadly, these generated no meaningful feedback from rustc at all,
except that they're suddenly failing in rustc beta!

After some back-and-forth, it seems rustc is moving forward
breaking existing code in future versions, so we move to the
"correct" check here, which is to check the raw IO error.

See rust-lang/rust#86442 and rust-lang/rust#85746 for more info.
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Aug 2, 2021
std::io::ErrorKind is a `#[non_exhaustive]` enum as more specific
error types are to be added in the future. It was unclear in the
docs until very recently, however, that this is to be done by
re-defining `ErrorKind::Other` errors to new enum variants. Thus,
our tests which check explicitly for `ErrorKind::Other` as a
result of trying to access a directory as a file were incorrect.
Sadly, these generated no meaningful feedback from rustc at all,
except that they're suddenly failing in rustc beta!

After some back-and-forth, it seems rustc is moving forward
breaking existing code in future versions, so we move to the
"correct" check here, which is to check the raw IO error.

See rust-lang/rust#86442 and rust-lang/rust#85746 for more info.
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Aug 2, 2021
std::io::ErrorKind is a `#[non_exhaustive]` enum as more specific
error types are to be added in the future. It was unclear in the
docs until very recently, however, that this is to be done by
re-defining `ErrorKind::Other` errors to new enum variants. Thus,
our tests which check explicitly for `ErrorKind::Other` as a
result of trying to access a directory as a file were incorrect.
Sadly, these generated no meaningful feedback from rustc at all,
except that they're suddenly failing in rustc beta!

After some back-and-forth, it seems rustc is moving forward
breaking existing code in future versions, so we move to the
"correct" check here, which is to check the raw IO error.

See rust-lang/rust#86442 and rust-lang/rust#85746 for more info.
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Aug 2, 2021
std::io::ErrorKind is a `#[non_exhaustive]` enum as more specific
error types are to be added in the future. It was unclear in the
docs until very recently, however, that this is to be done by
re-defining `ErrorKind::Other` errors to new enum variants. Thus,
our tests which check explicitly for `ErrorKind::Other` as a
result of trying to access a directory as a file were incorrect.
Sadly, these generated no meaningful feedback from rustc at all,
except that they're suddenly failing in rustc beta!

After some back-and-forth, it seems rustc is moving forward
breaking existing code in future versions, so we move to the
"correct" check here, which is to check the raw IO error.

See rust-lang/rust#86442 and rust-lang/rust#85746 for more info.
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Aug 2, 2021
std::io::ErrorKind is a `#[non_exhaustive]` enum as more specific
error types are to be added in the future. It was unclear in the
docs until very recently, however, that this is to be done by
re-defining `ErrorKind::Other` errors to new enum variants. Thus,
our tests which check explicitly for `ErrorKind::Other` as a
result of trying to access a directory as a file were incorrect.
Sadly, these generated no meaningful feedback from rustc at all,
except that they're suddenly failing in rustc beta!

After some back-and-forth, it seems rustc is moving forward
breaking existing code in future versions, so we move to the
"correct" check here, which is to check the raw IO error.

See rust-lang/rust#86442 and rust-lang/rust#85746 for more info.
Bobo1239 added a commit to Bobo1239/dua-cli that referenced this issue Sep 17, 2021
Rust 1.55 unfortunately breaks the existing code which assumed that
ErrorKind::Other will be returned by fs::read_dir() when a file is
encountered. For now just always try deleting as if it's a file with the
possibility to add the optimization back again once the `io_error_more`
feature is stabilized.

References:
- https://blog.rust-lang.org/2021/09/09/Rust-1.55.0.html#stdioerrorkind-variants-updated
- rust-lang/rust#85746
- rust-lang/rust#86442
Byron pushed a commit to Byron/dua-cli that referenced this issue Sep 18, 2021
Rust 1.55 unfortunately breaks the existing code which assumed that
ErrorKind::Other will be returned by fs::read_dir() when a file is
encountered. For now just always try deleting as if it's a file with the
possibility to add the optimization back again once the `io_error_more`
feature is stabilized.

References:
- https://blog.rust-lang.org/2021/09/09/Rust-1.55.0.html#stdioerrorkind-variants-updated
- rust-lang/rust#85746
- rust-lang/rust#86442
@rbtcollins
Copy link
Contributor

rbtcollins commented Sep 19, 2021

So in 1.55 this has broken our test suite for remove_dir_all by leaking into stable rather than being a nightly only feature.

It seems very poor form to return an enum variant to code which cannot match against it because the compiler considers it a nightly only feature. See XAMPPRocky/remove_dir_all#33 : the failing jobs are failing in stable because the change isn't present there, but putting the change into stable code results in:

error[E0658]: use of unstable library feature 'io_error_more'
  --> src/portable.rs:83:15
   |
83 |             &[io::ErrorKind::NotADirectory, io::ErrorKind::Other],
   |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |

To be really clear, my beef isn't with the breakage around Other, its that the new status quo means neither the old code nor the new code works. I'd like to see that remedied ASAP, since we can't run tests at all on stable today. Ironically, the tests are one @ijackson wrote ;)

@dtolnay
Copy link
Member

dtolnay commented Sep 19, 2021

@rbtcollins, to reiterate #86442 (comment), nothing is supposed to be comparing equality to ErrorKind::Other. Code that does this is wrong.

If the error kind is not one of the stable specific variants (non-Other), the correct way for stable code to match it is _ and new unstable variants have no bearing on that as they would continue to match _.

@rbtcollins
Copy link
Contributor

@dtolnay Ok, sure, we can fix this, probably by matching every other error type to exclude them but the definition has clearly shifted from 1.54 and before, and this leaves a pretty poor feeling here: https://blog.rust-lang.org/2014/10/30/Stability.html made a huge impression on me, and many others, and it seems like there was debate here, but the conclusion was to modify existing behaviour, rather than allowing edition based opt-in.

The 1.54 docs were:

Other
Any I/O error not part of this list.

Errors that are Other now may move to a different or a new ErrorKind variant in the future. 

This is very different to "must use _ to match" which implies must exhaustively match every other Kind to be moderately sure the desired error has occurred - which I don't look forward to doing.

@rbtcollins
Copy link
Contributor

Whats the right way to have a discussion about the ergonomics here? 85746 seems like a really awkward interface : theres no way that I know of to ergnomically say 'match only unstable entries'. So when one is interested in a concrete error, that is currently behind an unstable feature flag, the choices are to either accept 'any random error', or list all-known-errors as failure cases.

@lolbinarycat
Copy link
Contributor

one additional case that would be nice for this is "Too many open files" (EMFILE, 24 on linux)

i ran into this when writing async code, and there doesn't seem to be any way to test it besides checking the message.

@GoldsteinE
Copy link
Contributor

@lolbinarycat On Unix-like you can do .raw_os_error() to get an error code + nix::errno::Errno for a portable list of errnos.

@dr-kernel
Copy link

dr-kernel commented Jun 21, 2024

I would like to propose that we stabilize these. Based on the feedback above, these are very useful to have in stable, and there seem to be no real risks. Concretely, this would mean marking the following as stable:

* `io::ErrorKind::HostUnreachable`

* `io::ErrorKind::NetworkUnreachable`

* `io::ErrorKind::NetworkDown`

* `io::ErrorKind::NotADirectory`

* `io::ErrorKind::IsADirectory`

* `io::ErrorKind::DirectoryNotEmpty`

* `io::ErrorKind::ReadOnlyFilesystem`

* `io::ErrorKind::FilesystemLoop`

* `io::ErrorKind::StaleNetworkFileHandle`

* `io::ErrorKind::StorageFull`

* `io::ErrorKind::NotSeekable`

* `io::ErrorKind::FilesystemQuotaExceeded`

* `io::ErrorKind::FileTooLarge`

* `io::ErrorKind::ResourceBusy`

* `io::ErrorKind::ExecutableFileBusy`

* `io::ErrorKind::Deadlock`

* `io::ErrorKind::CrossesDevices`

* `io::ErrorKind::TooManyLinks`

* `io::ErrorKind::InvalidFilename`

* `io::ErrorKind::ArgumentListTooLong`

The issues around io::ErrorKind::Other and the unexpected failures they caused have been resolved with the introduction of io::ErrorKind::Uncategorized. This also eliminates the potential breakage from exhaustive matching. As such, stabilization itself should not be a breaking change anymore.

As to the concern raised by @m-ou-se, I have gone over all of these errors, and almost all of them seem to have compatible OS error conditions on both windows and any posix compliant system. As such, platform specific issues should only occur on unusual platforms outside of either the current tier 1 or tier 2 lists. I think we should be OK treating any cases where these errors are not generated currently as bugs. A further search of the current open issue list suggests no such issues are currently known.

There are two exceptions: First, io::ErrorKind::FilesystemQuotaExceeded and io::ErrorKind::FileTooLarge do not seem to correspond to posix standardised errors. I think for these in particular it is acceptable if they fall back to io::ErrorKind::StorageFull, which seems to be what the posix standard suggest would happen under those conditions. Second, io::ErrorKind::ExecutableFileBusy and io::ErrorKind::Deadlock seem to be best effort, and have limited system support, but this seems to me well enough documented.

Something I noticed that https://doc.rust-lang.org/stable/src/std/sys/pal/unix/mod.rs.html#261 uses HostUnreachable as the output of kind() however unless you're nightly you can't actually match to this since that variant is feature guarded. This is unfortunate since that's the kind that's returned by TcpStream when a host is offline. Thus when I'm trying to match this error type to attempt a retry, I can't unless I search for the code instead, not as convenient. This list needs to make its way to stable ASAP if its already being used to report errors. Whats worse is that this was done 3 years ago and no one has since complained that they can't match this kind w/o nightly?!

workingjubilee added a commit to workingjubilee/rustc that referenced this issue Sep 10, 2024
…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
workingjubilee added a commit to workingjubilee/rustc that referenced this issue Sep 10, 2024
…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
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Sep 10, 2024
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
@GrigorenkoPV
Copy link
Contributor

Status update

github-actions bot pushed a commit to rust-lang/miri that referenced this issue Sep 11, 2024
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: #86442
- FCP to stabilize it was completed 19(!!) months ago: rust-lang/rust#86442 (comment)
- A PR with stabilization was similarly open for 19 months: #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/rust#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/rust#106375 (comment)

> Maybe some less-controversial subset could be stabilized sooner? What’s blocking this issue from making progress? [^3]

[^3]: rust-lang/rust#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
workingjubilee added a commit to workingjubilee/rustc that referenced this issue Sep 11, 2024
Map `WSAEDQUOT` to `ErrorKind::FilesystemQuotaExceeded`

cc rust-lang#86442

As summarized in rust-lang#130190, there seems to be a consensus that this should be done.
workingjubilee added a commit to workingjubilee/rustc that referenced this issue Sep 11, 2024
…LENAME, r=ChrisDenton

Map `ERROR_CANT_RESOLVE_FILENAME` to `ErrorKind::FilesystemLoop`

cc rust-lang#86442

As summarized in rust-lang#130188, there seems to be a consensus that this should be done.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Sep 11, 2024
Map `WSAEDQUOT` to `ErrorKind::FilesystemQuotaExceeded`

cc rust-lang#86442

As summarized in rust-lang#130190, there seems to be a consensus that this should be done.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Sep 11, 2024
…LENAME, r=ChrisDenton

Map `ERROR_CANT_RESOLVE_FILENAME` to `ErrorKind::FilesystemLoop`

cc rust-lang#86442

As summarized in rust-lang#130188, there seems to be a consensus that this should be done.
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Sep 11, 2024
Rollup merge of rust-lang#130207 - GrigorenkoPV:ERROR_CANT_RESOLVE_FILENAME, r=ChrisDenton

Map `ERROR_CANT_RESOLVE_FILENAME` to `ErrorKind::FilesystemLoop`

cc rust-lang#86442

As summarized in rust-lang#130188, there seems to be a consensus that this should be done.
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Sep 11, 2024
Rollup merge of rust-lang#130206 - GrigorenkoPV:WSAEDQUOT, r=ChrisDenton

Map `WSAEDQUOT` to `ErrorKind::FilesystemQuotaExceeded`

cc rust-lang#86442

As summarized in rust-lang#130190, there seems to be a consensus that this should be done.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-error-handling Area: Error handling A-io Area: `std::io`, `std::fs`, `std::net` and `std::path` C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.