Tracking Issue for io_error_more #86442
Comments
ijackson
added
C-tracking-issue
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. |
|
https://doc.rust-lang.org/std/path/struct.Path.html#method.is_dir documents:
I’ve implemented this by coercing 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 |
Yes, it was checking that an error was |
|
@TheBlueMatt
#85746 is the change that made the standard library stop returning We do want to stabilize these new variants soon. But in the meantime, if you have code that matches |
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.
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 |
|
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. 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 My view is that the new Whether avoiding a substantial delay to new 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 I want to reply separately about what alternative idiom I think your tests should probably use. |
|
On Thu, Jul 29, 2021 at 12:22:18PM -0700, Matt Corallo wrote:
> 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,
If you're not checking for any specific error code, then I don't think
it makes sense to check for `Other` at all. That would *inherently*
break if a new ErrorKind variant were ever added. `ErrorKind` is
`#[non_exhaustive]` precisely to allow adding new error types; as a
result, asserting "this is an error type that doesn't have a more
specific enum variant" is inherently fragile and
non-forwards-compatible.
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.
It seems inherently unreliable to match `Other` for anything other than
"some error I don't know about", given the above. Code doing that in a
match without a `_` branch would already get a warning about
`#[non_exhaustive]`. So the only way to have this happen would be an
`==` or `if let` or similar, or an assert.
We could add a clippy lint against asserts that match `Other` without an
error code. That might have some false-positives, for code that actually
uses Other for something other than an unhandled errno value, but it
might still be viable as a clippy lint.
|
|
On Jul 29, 2021, at 17:01, Ian Jackson ***@***.***> wrote:
Hi, @TheBlueMatt
As the author of the MR 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.
First of all, it’s software, things happen, in our case it was just some minor check in a test, no sweat!
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...)
Indeed, sadly because clippy requires rustup I generally can’t use it anyway. :(
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).
I do wonder if it’s practical to do this in an edition? The next edition isn’t shaping up to be that far away, and adding this kind is breaking thing seems like a great candidate for such a thing! I’m not suggesting waiting for editions for every new variant, but doing the first new additions in an edition with more linting may avoid a lot of this.
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.
Makes sense, there’s quite a tradeoff here, but I do really worry about stability of rust here, and the guarantees around upstream not breaking existing code seemed stronger than they appear to be now. I suppose I just weigh stability differently.
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.
Partially. I agree that’s what it implies, but the explicit mention was only added very recently, and for those of us not super deep in the libstd world I guess it didn’t come across until now.
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 ?
I would think at least simple checks could happen in rustc and not clippy. Eg matching/comparing equality on a non-exhaustive enum with an “other” variant seems like something that rustc could warn on, though I admit I’m not on any way familiar with the rustc codebase, so feel free to tell me I’m wrong.
… 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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
@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 One other note: #85746 (which is the change that actually affected your test) is targeted at 1.55, and has a |
I'm curious if extending the |
No, we didn't think of that.
Now that #85746 has landed, I don't think this situation can arise again with I don't know if there are other enums in the stdlib with similar properties to |
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.
Ah, maybe I partially misunderstood the way 85746 operates. |
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.
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.
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.
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.
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.
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.
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
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
|
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: 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 ;) |
|
@rbtcollins, to reiterate #86442 (comment), nothing is supposed to be comparing equality to If the error kind is not one of the stable specific variants (non- |
|
@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: 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. |
|
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. |
|
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. |
|
@lolbinarycat On Unix-like you can do |
Something I noticed that https://doc.rust-lang.org/stable/src/std/sys/pal/unix/mod.rs.html#261 uses |
…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
…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
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
Status update
|
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
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.
…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.
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.
…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.
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.
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.
and others
Feature gate:
#![feature(io_error_more)]This is a tracking issue for many
io::ErrorKindvariants 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::Foofor manyFoo. I will paste a list here when the MR is merged :-).Steps / History
io_error_more#128316Unresolved Questions
ErrorKindvariants ? It may not be necessary to resolve this wider question in order to stabilise this particular set ofErrorKinds.The text was updated successfully, but these errors were encountered: