Redefine `ErrorKind::Other` and stop using it in std. #85746

m-ou-se · 2021-05-27T12:16:38Z

This implements the idea I shared yesterday in the libs meeting when we were discussing how to handle adding new ErrorKinds to the standard library: This redefines Other to be for user defined errors only, and changes all uses of Other in the standard library to a #[doc(hidden)] and permanently #[unstable] ErrorKind that users can not match on. This ensures that adding ErrorKinds at a later point in time is not a breaking change, since the user couldn't match on these errors anyway. This way, we use the #[non_exhaustive] property of the enum in a more effective way.

Open questions:

How do we check this change doesn't cause too much breakage? Will a crate run help and be enough?
How do we ensure we don't accidentally start using Other again in the standard library? We don't have a pub(not crate) or #[deprecated(in this crate only)].

cc #79965

cc @rust-lang/libs @ijackson

r? @dtolnay

Mark-Simulacrum · 2021-05-27T12:41:55Z

FWIW I don't think a crater run will give useful data here; removing Other entirely and running a crater run there might give us the places where people are doing something with it and then go from there manually. But my guess is there's going to be a lot of code that does that...

CDirkx · 2021-05-27T13:39:58Z

Regarding how to ensure we don't use Other, maybe it could be implemented as a tidy check. Similar to the "Platform Abstraction Layer" (src/tools/tidy/src/pal.rs), which essentially performs a text search for "#[cfg(target_os = ...)]" etc., we could search for "ErrorKind::Other". This might not catch all cases as it doesn't use type information, but might be good enough for an internal lint for std.

jyn514 · 2021-05-27T13:54:01Z

You could also add an allow-by-default lint meant only for the standard library.

joshtriplett · 2021-05-27T17:54:57Z

A crater run won't be definitive, but it'll catch cases where it affects someone's testsuite at least.

Regarding use in the standard library, I think a tidy check for ErrorKind::Other would be a good start for now, and we can always add something more later.

yaahc · 2021-05-27T19:30:12Z

Some comments:

I'm not a fan of calling this Unknown and worry that it doesn't accurately describe these kinds of errors
- The debug impl output might be confusing, Repr::Custom { kind: ErrorKind::Unknown, .. }
- Users may read this from an unwrap and think this means they encountered a custom error of unknown origin, whatever that means.
I think we should call this Unclassified instead of Unknown
- ErrorKind exists to classify errors, and each kind may abstract over multiple underlying source errors
- More aligned with the stability policy of reserving the right to reclassify errors in the future
- Alternative names I've considered: Unstable, Internal, None
Is it accurate to describe these as all being os errors in the documentation and Display impl for ErrorKind?
- It doesn't seem like all of these are being used to represent os errors
- What precisely does it mean to be an OS error? Is it the presence of an associated Error code? That seems restrictive / bad, so hopefully not
- if we want "os error" to mean "errors with error codes" then perhaps we should actually be introducing two new variants, one of which we only use in the various implementations of decode_error_kind
- if we think it means "any error that originates from an os API" then this seems fine

m-ou-se · 2021-05-27T19:43:00Z

Yeah the name Unknown is just a bikeshed placeholder. We should put something better there.

I just left the "other os error" message as it was. I only removed "os" from Other because that's now only used for user errors. But maybe it's time to update it, as it's not really accurate. Maybe both should be just "other error".

joshtriplett · 2021-05-27T20:48:27Z

"Unclassified" seems good to me.

m-ou-se · 2021-05-27T20:56:48Z

Unclassified - (of data, documents, etc.) not belonging to a category that is restricted for reasons of security; not secret:

That sounds completely opposite of #[doc(hidden)] #[unstable] ;)

(Not that ErrorKind::TopSecret would be better. ^^)

yaahc · 2021-05-27T21:21:51Z

I just left the "other os error" message as it was. I only removed "os" from Other because that's now only used for user errors. But maybe it's time to update it, as it's not really accurate. Maybe both should be just "other error".

Oh, I should have paid more attention to the before part of the diff. If these are up for grabs then I'd probably go with "user error" for ErrorKind::Other and "other error" or "unclassified error" for ErrorKind::Bikeshed. For the second one I'd normally prefer "other error" but I'm worried it will be confusing because there is an ErrorKind::Other that you'd think would be associated with this description. This is making me lean strongly towards wanting to just deprecate ErrorKind::Other and introduce an ErrorKind::User or something to replace it.

joshtriplett · 2021-05-27T21:47:04Z

@yaahc I think such a deprecation would cause a large amount of churn. I'd rather keep Other for user-specified errors, and just introduce a separate "unclassified OS error code" or similar.

library/std/src/io/error.rs

library/std/src/sys/hermit/net.rs

library/std/src/sys/windows/fs.rs

joshtriplett · 2021-05-27T22:17:09Z

I posted a few minor comments. Otherwise, this LGTM, and I'd be happy to see it FCPed once we settle naming and messages.

joshtriplett · 2021-05-31T20:10:48Z

In the interests of seeking consensus, I'm proposing this for FCP, while also raising a concern to reflect that we haven't settled on a final name or user-visible messages yet. (That said, the name is permanently unstable, so I think the user-visible messages are more important.)

@rfcbot merge

@rfcbot concern naming-and-messages

rfcbot · 2021-05-31T20:10:49Z

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

Concerns:

~~naming-and-messages~~ resolved by Redefine ErrorKind::Other and stop using it in std. #85746 (comment)

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.

bors · 2021-07-02T11:42:33Z

☀️ Test successful - checks-actions
Approved by: joshtriplett
Pushing f9fa13f to master...

io::ErrorKind just replaced most uses of "Other" with "Uncategorized" and prohibits users from matching on "Uncategorized". So match on the errno instead. rust-lang/rust#85746

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.

Per rust-lang/rust#85746, Rust 1.55 has stopped returning io::ErrorKind::Other from within the standard library and instead returns better, more-specific error codes. This broke a test of ours that matched on `Other`. Address this by relaxing the test and only checking for an error, not the specific error type. Fixing this properly seems quite hard at this point per the added TODO.

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

Pkgsrc changes: * Bump bootstrap kit version to 1.55.0. * Adjust patches as needed, some no longer apply (so removed) * Update checksum adjustments. * Avoid rust-llvm on SunOS * Optionally build docs * Remove reference to closed/old PR#54621 Upstream changes: Version 1.56.1 (2021-11-01) =========================== - New lints to detect the presence of bidirectional-override Unicode codepoints in the compiled source code ([CVE-2021-42574]) [CVE-2021-42574]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-42574 Version 1.56.0 (2021-10-21) ======================== Language -------- - [The 2021 Edition is now stable.][rust#88100] See [the edition guide][rust-2021-edition-guide] for more details. - [The pattern in `binding @ pattern` can now also introduce new bindings.] [rust#85305] - [Union field access is permitted in `const fn`.][rust#85769] [rust-2021-edition-guide]: https://doc.rust-lang.org/nightly/edition-guide/rust-2021/index.html Compiler -------- - [Upgrade to LLVM 13.][rust#87570] - [Support memory, address, and thread sanitizers on aarch64-unknown-freebsd.] [rust#88023] - [Allow specifying a deployment target version for all iOS targets][rust#87699] - [Warnings can be forced on with `--force-warn`.][rust#87472] This feature is primarily intended for usage by `cargo fix`, rather than end users. - [Promote `aarch64-apple-ios-sim` to Tier 2\*.][rust#87760] - [Add `powerpc-unknown-freebsd` at Tier 3\*.][rust#87370] - [Add `riscv32imc-esp-espidf` at Tier 3\*.][rust#87666] \* Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. Libraries --------- - [Allow writing of incomplete UTF-8 sequences via stdout/stderr on Windows.] [rust#83342] The Windows console still requires valid Unicode, but this change allows splitting a UTF-8 character across multiple write calls. This allows, for instance, programs that just read and write data buffers (e.g. copying a file to stdout) without regard for Unicode or character boundaries. - [Prefer `AtomicU{64,128}` over Mutex for Instant backsliding protection.] [rust#83093] For this use case, atomics scale much better under contention. - [Implement `Extend<(A, B)>` for `(Extend<A>, Extend<B>)`][rust#85835] - [impl Default, Copy, Clone for std::io::Sink and std::io::Empty][rust#86744] - [`impl From<[(K, V); N]>` for all collections.][rust#84111] - [Remove `P: Unpin` bound on impl Future for Pin.][rust#81363] - [Treat invalid environment variable names as non-existent.][rust#86183] Previously, the environment functions would panic if given a variable name with an internal null character or equal sign (`=`). Now, these functions will just treat such names as non-existent variables, since the OS cannot represent the existence of a variable with such a name. Stabilised APIs --------------- - [`std::os::unix::fs::chroot`] - [`UnsafeCell::raw_get`] - [`BufWriter::into_parts`] - [`core::panic::{UnwindSafe, RefUnwindSafe, AssertUnwindSafe}`] These APIs were previously stable in `std`, but are now also available in `core`. - [`Vec::shrink_to`] - [`String::shrink_to`] - [`OsString::shrink_to`] - [`PathBuf::shrink_to`] - [`BinaryHeap::shrink_to`] - [`VecDeque::shrink_to`] - [`HashMap::shrink_to`] - [`HashSet::shrink_to`] These APIs are now usable in const contexts: - [`std::mem::transmute`] - [`[T]::first`][`slice::first`] - [`[T]::split_first`][`slice::split_first`] - [`[T]::last`][`slice::last`] - [`[T]::split_last`][`slice::split_last`] Cargo ----- - [Cargo supports specifying a minimum supported Rust version in Cargo.toml.] [`rust-version`] This has no effect at present on dependency version selection. We encourage crates to specify their minimum supported Rust version, and we encourage CI systems that support Rust code to include a crate's specified minimum version in the text matrix for that crate by default. Compatibility notes ------------------- - [Update to new argument parsing rules on Windows.][rust#87580] This adjusts Rust's standard library to match the behavior of the standard libraries for C/C++. The rules have changed slightly over time, and this PR brings us to the latest set of rules (changed in 2008). - [Disallow the aapcs calling convention on aarch64][rust#88399] This was already not supported by LLVM; this change surfaces this lack of support with a better error message. - [Make `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` warn by default][rust#87385] - [Warn when an escaped newline skips multiple lines.][rust#87671] - [Calls to `libc::getpid` / `std::process::id` from `Command::pre_exec` may return different values on glibc <= 2.24.][rust#81825] Rust now invokes the `clone3` system call directly, when available, to use new functionality available via that system call. Older versions of glibc cache the result of `getpid`, and only update that cache when calling glibc's clone/fork functions, so a direct system call bypasses that cache update. glibc 2.25 and newer no longer cache `getpid` for exactly this reason. Internal changes ---------------- These changes provide no direct user facing benefits, but represent significant improvements to the internals and overall performance of rustc and related tools. - [LLVM is compiled with PGO in published x86_64-unknown-linux-gnu artifacts.] [rust#88069] This improves the performance of most Rust builds. - [Unify representation of macros in internal data structures.][rust#88019] This change fixes a host of bugs with the handling of macros by the compiler, as well as rustdoc. [`std::os::unix::fs::chroot`]: https://doc.rust-lang.org/stable/std/os/unix/fs/fn.chroot.html [`Iterator::intersperse`]: https://doc.rust-lang.org/stable/std/iter/trait.Iterator.html#method.intersperse [`Iterator::intersperse_with`]: https://doc.rust-lang.org/stable/std/iter/trait.Iterator.html#method.intersperse [`UnsafeCell::raw_get`]: https://doc.rust-lang.org/stable/std/cell/struct.UnsafeCell.html#method.raw_get [`BufWriter::into_parts`]: https://doc.rust-lang.org/stable/std/io/struct.BufWriter.html#method.into_parts [`core::panic::{UnwindSafe, RefUnwindSafe, AssertUnwindSafe}`]: rust-lang/rust#84662 [`Vec::shrink_to`]: https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#method.shrink_to [`String::shrink_to`]: https://doc.rust-lang.org/stable/std/string/struct.String.html#method.shrink_to [`OsString::shrink_to`]: https://doc.rust-lang.org/stable/std/ffi/struct.OsString.html#method.shrink_to [`PathBuf::shrink_to`]: https://doc.rust-lang.org/stable/std/path/struct.PathBuf.html#method.shrink_to [`BinaryHeap::shrink_to`]: https://doc.rust-lang.org/stable/std/collections/struct.BinaryHeap.html#method.shrink_to [`VecDeque::shrink_to`]: https://doc.rust-lang.org/stable/std/collections/struct.VecDeque.html#method.shrink_to [`HashMap::shrink_to`]: https://doc.rust-lang.org/stable/std/collections/hash_map/struct.HashMap.html#method.shrink_to [`HashSet::shrink_to`]: https://doc.rust-lang.org/stable/std/collections/hash_set/struct.HashSet.html#method.shrink_to [`std::mem::transmute`]: https://doc.rust-lang.org/stable/std/mem/fn.transmute.html [`slice::first`]: https://doc.rust-lang.org/stable/std/primitive.slice.html#method.first [`slice::split_first`]: https://doc.rust-lang.org/stable/std/primitive.slice.html#method.split_first [`slice::last`]: https://doc.rust-lang.org/stable/std/primitive.slice.html#method.last [`slice::split_last`]: https://doc.rust-lang.org/stable/std/primitive.slice.html#method.split_last [`rust-version`]: https://doc.rust-lang.org/nightly/cargo/reference/manifest.html#the-rust-version-field [rust#87671]: rust-lang/rust#87671 [rust#86183]: rust-lang/rust#86183 [rust#87385]: rust-lang/rust#87385 [rust#88100]: rust-lang/rust#88100 [rust#86860]: rust-lang/rust#86860 [rust#84039]: rust-lang/rust#84039 [rust#86492]: rust-lang/rust#86492 [rust#88363]: rust-lang/rust#88363 [rust#85305]: rust-lang/rust#85305 [rust#87832]: rust-lang/rust#87832 [rust#88069]: rust-lang/rust#88069 [rust#87472]: rust-lang/rust#87472 [rust#87699]: rust-lang/rust#87699 [rust#87570]: rust-lang/rust#87570 [rust#88023]: rust-lang/rust#88023 [rust#87760]: rust-lang/rust#87760 [rust#87370]: rust-lang/rust#87370 [rust#87580]: rust-lang/rust#87580 [rust#83342]: rust-lang/rust#83342 [rust#83093]: rust-lang/rust#83093 [rust#88177]: rust-lang/rust#88177 [rust#88548]: rust-lang/rust#88548 [rust#88551]: rust-lang/rust#88551 [rust#88299]: rust-lang/rust#88299 [rust#88220]: rust-lang/rust#88220 [rust#85835]: rust-lang/rust#85835 [rust#86879]: rust-lang/rust#86879 [rust#86744]: rust-lang/rust#86744 [rust#84662]: rust-lang/rust#84662 [rust#86593]: rust-lang/rust#86593 [rust#81050]: rust-lang/rust#81050 [rust#81363]: rust-lang/rust#81363 [rust#84111]: rust-lang/rust#84111 [rust#85769]: rust-lang/rust#85769 (comment) [rust#88490]: rust-lang/rust#88490 [rust#88269]: rust-lang/rust#88269 [rust#84176]: rust-lang/rust#84176 [rust#88399]: rust-lang/rust#88399 [rust#88227]: rust-lang/rust#88227 [rust#88200]: rust-lang/rust#88200 [rust#82776]: rust-lang/rust#82776 [rust#88077]: rust-lang/rust#88077 [rust#87728]: rust-lang/rust#87728 [rust#87050]: rust-lang/rust#87050 [rust#87619]: rust-lang/rust#87619 [rust#81825]: rust-lang/rust#81825 (comment) [rust#88019]: rust-lang/rust#88019 [rust#87666]: rust-lang/rust#87666 Version 1.55.0 (2021-09-09) ============================ Language -------- - [You can now write open "from" range patterns (`X..`), which will start at `X` and will end at the maximum value of the integer.][83918] - [You can now explicitly import the prelude of different editions through `std::prelude` (e.g. `use std::prelude::rust_2021::*;`).][86294] Compiler -------- - [Added tier 3\* support for `powerpc64le-unknown-freebsd`.][83572] \* Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. Libraries --------- - [Updated std's float parsing to use the Eisel-Lemire algorithm.][86761] These improvements should in general provide faster string parsing of floats, no longer reject certain valid floating point values, and reduce the produced code size for non-stripped artifacts. - [`string::Drain` now implements `AsRef<str>` and `AsRef<[u8]>`.][86858] Stabilised APIs --------------- - [`Bound::cloned`] - [`Drain::as_str`] - [`IntoInnerError::into_error`] - [`IntoInnerError::into_parts`] - [`MaybeUninit::assume_init_mut`] - [`MaybeUninit::assume_init_ref`] - [`MaybeUninit::write`] - [`array::map`] - [`ops::ControlFlow`] - [`x86::_bittest`] - [`x86::_bittestandcomplement`] - [`x86::_bittestandreset`] - [`x86::_bittestandset`] - [`x86_64::_bittest64`] - [`x86_64::_bittestandcomplement64`] - [`x86_64::_bittestandreset64`] - [`x86_64::_bittestandset64`] The following previously stable functions are now `const`. - [`str::from_utf8_unchecked`] Cargo ----- - [Cargo will now deduplicate compiler diagnostics to the terminal when invoking rustc in parallel such as when using `cargo test`.][cargo/9675] - [The package definition in `cargo metadata` now includes the `"default_run"` field from the manifest.][cargo/9550] - [Added `cargo d` as an alias for `cargo doc`.][cargo/9680] - [Added `{lib}` as formatting option for `cargo tree` to print the `"lib_name"` of packages.][cargo/9663] Rustdoc ------- - [Added "Go to item on exact match" search option.][85876] - [The "Implementors" section on traits no longer shows redundant method definitions.][85970] - [Trait implementations are toggled open by default.][86260] This should make the implementations more searchable by tools like `CTRL+F` in your browser. - [Intra-doc links should now correctly resolve associated items (e.g. methods) through type aliases.][86334] - [Traits which are marked with `#[doc(hidden)]` will no longer appear in the "Trait Implementations" section.][86513] Compatibility Notes ------------------- - [std functions that return an `io::Error` will no longer use the `ErrorKind::Other` variant.][85746] This is to better reflect that these kinds of errors could be categorised [into newer more specific `ErrorKind` variants][79965], and that they do not represent a user error. - [Using environment variable names with `process::Command` on Windows now behaves as expected.][85270] Previously using envionment variables with `Command` would cause them to be ASCII-uppercased. - [Rustdoc will now warn on using rustdoc lints that aren't prefixed with `rustdoc::`][86849] [86849]: rust-lang/rust#86849 [86513]: rust-lang/rust#86513 [86334]: rust-lang/rust#86334 [86260]: rust-lang/rust#86260 [85970]: rust-lang/rust#85970 [85876]: rust-lang/rust#85876 [83572]: rust-lang/rust#83572 [86294]: rust-lang/rust#86294 [86858]: rust-lang/rust#86858 [86761]: rust-lang/rust#86761 [85769]: rust-lang/rust#85769 [85746]: rust-lang/rust#85746 [85305]: rust-lang/rust#85305 [85270]: rust-lang/rust#85270 [84111]: rust-lang/rust#84111 [83918]: rust-lang/rust#83918 [79965]: rust-lang/rust#79965 [87370]: rust-lang/rust#87370 [87298]: rust-lang/rust#87298 [cargo/9663]: rust-lang/cargo#9663 [cargo/9675]: rust-lang/cargo#9675 [cargo/9550]: rust-lang/cargo#9550 [cargo/9680]: rust-lang/cargo#9680 [cargo/9663]: rust-lang/cargo#9663 [`array::map`]: https://doc.rust-lang.org/stable/std/primitive.array.html#method.map [`Bound::cloned`]: https://doc.rust-lang.org/stable/std/ops/enum.Bound.html#method.cloned [`Drain::as_str`]: https://doc.rust-lang.org/stable/std/string/struct.Drain.html#method.as_str [`IntoInnerError::into_error`]: https://doc.rust-lang.org/stable/std/io/struct.IntoInnerError.html#method.into_error [`IntoInnerError::into_parts`]: https://doc.rust-lang.org/stable/std/io/struct.IntoInnerError.html#method.into_parts [`MaybeUninit::assume_init_mut`]: https://doc.rust-lang.org/stable/std/mem/union.MaybeUninit.html#method.assume_init_mut [`MaybeUninit::assume_init_ref`]: https://doc.rust-lang.org/stable/std/mem/union.MaybeUninit.html#method.assume_init_ref [`MaybeUninit::write`]: https://doc.rust-lang.org/stable/std/mem/union.MaybeUninit.html#method.write [`Seek::rewind`]: https://doc.rust-lang.org/stable/std/io/trait.Seek.html#method.rewind [`ops::ControlFlow`]: https://doc.rust-lang.org/stable/std/ops/enum.ControlFlow.html [`str::from_utf8_unchecked`]: https://doc.rust-lang.org/stable/std/str/fn.from_utf8_unchecked.html [`x86::_bittest`]: https://doc.rust-lang.org/stable/core/arch/x86/fn._bittest.html [`x86::_bittestandcomplement`]: https://doc.rust-lang.org/stable/core/arch/x86/fn._bittestandcomplement.html [`x86::_bittestandreset`]: https://doc.rust-lang.org/stable/core/arch/x86/fn._bittestandreset.html [`x86::_bittestandset`]: https://doc.rust-lang.org/stable/core/arch/x86/fn._bittestandset.html [`x86_64::_bittest64`]: https://doc.rust-lang.org/stable/core/arch/x86_64/fn._bittest64.html [`x86_64::_bittestandcomplement64`]: https://doc.rust-lang.org/stable/core/arch/x86_64/fn._bittestandcomplement64.html [`x86_64::_bittestandreset64`]: https://doc.rust-lang.org/stable/core/arch/x86_64/fn._bittestandreset64.html [`x86_64::_bittestandset64`]: https://doc.rust-lang.org/stable/core/arch/x86_64/fn._bittestandset64.html

After rust-lang/rust#85746 , `ErrorKind::Other` is not what it used to. This library depended on `ErrorKind::Other` in a couple places for error handling, and that's I believe why the tests were failing. I've changed those bits of error handling to rely on the `raw_os_error` instead. This should be more granular than the `kind`, but also more stable. I believe I've chosen the right error codes that we were supposed to handle, and the tests now pass (in my machine anyway lol). I've also changed a couple doc tests that were failing to compile. After these changes, running `cargo test` succeeds.

io::ErrorKind::Other no longer gets returned by std as of rust-lang/rust#85746 In lieu of requiring the io_error_more feature, match against the raw_os_error directly Fixes cargo-lambda#70

m-ou-se added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. A-io Area: std::io, std::fs, std::net and std::path labels May 27, 2021

rust-highfive assigned dtolnay May 27, 2021

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 27, 2021

m-ou-se force-pushed the io-error-other branch from 09cf815 to 0c3c686 Compare May 27, 2021 12:19

m-ou-se mentioned this pull request May 27, 2021

More ErrorKinds for common errnos #79965

Merged

m-ou-se added the needs-fcp This change is insta-stable, so needs a completed FCP to proceed. label May 27, 2021

This comment has been minimized.

Sign in to view

m-ou-se force-pushed the io-error-other branch from 0c3c686 to 42fd332 Compare May 27, 2021 12:48

joshtriplett reviewed May 27, 2021

View reviewed changes

library/std/src/io/error.rs Show resolved Hide resolved

joshtriplett reviewed May 27, 2021

View reviewed changes

library/std/src/io/error.rs Outdated Show resolved Hide resolved

joshtriplett reviewed May 27, 2021

View reviewed changes

library/std/src/sys/hermit/net.rs Outdated Show resolved Hide resolved

joshtriplett reviewed May 27, 2021

View reviewed changes

library/std/src/sys/windows/fs.rs Outdated Show resolved Hide resolved

joshtriplett added the relnotes Marks issues that should be documented in the release notes of the next release. label May 27, 2021

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 May 31, 2021

Redefine ErrorKind::Other and stop using it in std.

0b37bb2

bors added the merged-by-bors This PR was explicitly merged by bors. label Jul 2, 2021

bors merged commit f9fa13f into rust-lang:master Jul 2, 2021

rustbot added this to the 1.55.0 milestone Jul 2, 2021

m-ou-se deleted the io-error-other branch July 2, 2021 18:31

asomers mentioned this pull request Jul 10, 2021

Fix the uds_datagram tests with the latest nightly stdlib tokio-rs/tokio#3952

Merged

joshtriplett mentioned this pull request Jul 29, 2021

Tracking Issue for io_error_more #86442

Open

4 tasks

Bobo1239 mentioned this pull request Sep 17, 2021

Fix deletion process on Rust 1.55 Byron/dua-cli#107

Merged

BraulioVM mentioned this pull request Dec 30, 2021

Test failure: Os { code: 9, kind: Uncategorized, message: "Bad file descriptor" } tokio-rs/tokio-uring#59

Closed

BraulioVM mentioned this pull request Dec 31, 2021

fix build and test errors tokio-rs/tokio-uring#69

Merged

sdd mentioned this pull request Apr 18, 2022

"Invalid cross-device link" when running cargo lambda new blah on Manjaro cargo-lambda/cargo-lambda#70

Closed

sdd mentioned this pull request Apr 18, 2022

rename no longer uses io::ErrorKind::Other cargo-lambda/cargo-lambda#72

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Redefine `ErrorKind::Other` and stop using it in std. #85746

Redefine `ErrorKind::Other` and stop using it in std. #85746

m-ou-se commented May 27, 2021

This comment has been minimized.

Mark-Simulacrum commented May 27, 2021

CDirkx commented May 27, 2021 •

edited

Loading

jyn514 commented May 27, 2021

joshtriplett commented May 27, 2021

yaahc commented May 27, 2021

m-ou-se commented May 27, 2021

joshtriplett commented May 27, 2021

m-ou-se commented May 27, 2021 •

edited

Loading

yaahc commented May 27, 2021 •

edited

Loading

joshtriplett commented May 27, 2021

joshtriplett commented May 27, 2021

joshtriplett commented May 31, 2021

rfcbot commented May 31, 2021 •

edited

Loading

bors commented Jul 2, 2021

Redefine ErrorKind::Other and stop using it in std. #85746

Redefine ErrorKind::Other and stop using it in std. #85746

Conversation

m-ou-se commented May 27, 2021

This comment has been minimized.

Mark-Simulacrum commented May 27, 2021

CDirkx commented May 27, 2021 • edited Loading

jyn514 commented May 27, 2021

joshtriplett commented May 27, 2021

yaahc commented May 27, 2021

m-ou-se commented May 27, 2021

joshtriplett commented May 27, 2021

m-ou-se commented May 27, 2021 • edited Loading

yaahc commented May 27, 2021 • edited Loading

joshtriplett commented May 27, 2021

joshtriplett commented May 27, 2021

joshtriplett commented May 31, 2021

rfcbot commented May 31, 2021 • edited Loading

bors commented Jul 2, 2021

Redefine `ErrorKind::Other` and stop using it in std. #85746

Redefine `ErrorKind::Other` and stop using it in std. #85746

CDirkx commented May 27, 2021 •

edited

Loading

m-ou-se commented May 27, 2021 •

edited

Loading

yaahc commented May 27, 2021 •

edited

Loading

rfcbot commented May 31, 2021 •

edited

Loading