Move `std::io::ErrorKind` to `core::io` by bushrat011899 · Pull Request #154654 · rust-lang/rust

bushrat011899 · 2026-04-01T01:07:08Z

ACP: rust-lang/libs-team#755
Tracking issue: #154046
Related: #152918

Description

I consider #154046 to be really important for no_std, but I'm concerned #152918 might be too controversial. As an alternative, I'd like to propose starting small with ErrorKind, since it can be moved somewhat trivially. It has no dependencies on functionality in std, no platform specific behaviour, and could provide an excellent bridging point for no_std IO libraries.

Since std::io::Error implements From<ErrorKind>, libraries could write functions which return Result<T, core::io::ErrorKind>, and therefore be usable in std-using libraries with the ? operator. For that reason, I'd consider this to be a worthwhile change even if the rest of std::io couldn't be moved to core/alloc, and entirely compatible with any efforts to make such a change in the future.

Notes

This is my first PR against Rust, please let me know if there's anything I should be doing that I have not done. I tried reading through the library contributors guide but I'm sure I've missed something.
No AI tooling of any kind was used in the creation of this PR.
I believe it's appropriate that this be a part of the linked tracking issue, but please let me know if that's not the case!

rustbot · 2026-04-01T01:07:13Z

r? @Mark-Simulacrum

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

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: @ChrisDenton, libs
@ChrisDenton, libs expanded to 8 candidates

a1phyr · 2026-04-01T11:51:29Z

I'm concerned #152918 might be too controversial.

It may be controversial, but it has been accepted in principle by libs-teams, so it should be fine.

bushrat011899 · 2026-04-01T12:12:13Z

I'm concerned #152918 might be too controversial.

It may be controversial, but it has been accepted in principle by libs-teams, so it should be fine.

I hope so! I really want your PR to land. Regardless of whether it does, this is a good follow-up to go further at basically no cost.

lygstate · 2026-04-01T18:35:45Z

looks good to me

library/core/src/io/error.rs

library/std/src/io/error/repr_bitpacked.rs

rustbot · 2026-04-04T16:12:22Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

bushrat011899 · 2026-04-07T11:09:01Z

@rustbot ready

Mark-Simulacrum · 2026-04-11T14:41:21Z

library/core/src/lib.rs

 pub mod char;
 pub mod ffi;
-#[unstable(feature = "core_io_borrowed_buf", issue = "117693")]
+#[unstable(feature = "core_io", issue = "154046")]


View changes since the review

Hm, I suspect we should stabilize the module existing (while leaving everything in it unstable). Otherwise it's annoying for everyone downstream to need two feature gates, and I think it's highly likely we do in fact want the module long-term.

Let me nominate #154046 for libs-api so they can decide if that seems reasonable.

I assume that would need to be done in a different PR, and this rebased if/when that's merged?

Based on this comment I'm merging io_error_kind_in_core into core_io. As a followup, it may be worth removing the core_io_borrowed_buf feature entirely, and using the read_buf feature std::io uses for BorrowedBuf and BorrowedCursor instead. That would still require two features to use borrowed buffers from core, but one of those is already required to use it from std anyway, so I think not too bad.

library/core/src/io/error.rs

bushrat011899 · 2026-04-12T02:45:36Z

@rustbot blocked

Marking as blocked until the module core::io is stabilised. Without its stabilisation, there is an unfortunate interaction between a features enabling core::io::ErrorKind and core::io::BorrowedBuf.

Certain links will not be valid when moved into `core::io`

* Checking exhaustion will no longer be possible for `repr_bitpacked`. Moving `kind_from_prim` into an associated function, and setting it up to be moved into `core::io` as well. * `ErrorKind::as_str` is private, but it's only usage is trivially replaced with `Display::fmt` * The features io_error_inprogress, io_error_more, and io_error_uncategorized will all need to be enabled

Move `std::io::ErrorKind` to `core::io` * Update `rustdoc-html` tests for the new path * Add `core_io` feature to control stability. This replaces the use of `core_io_borrowed_buf` on the `core::io` module itself. * Re-export `core::io::ErrorKind` in `std::io::error`

rustbot · 2026-04-14T23:13:49Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

bushrat011899 · 2026-04-14T23:19:38Z

@rustbot ready
See this comment regarding the choice to use core_io to gate core::io and core::io::ErrorKind.

rustbot assigned Mark-Simulacrum Apr 1, 2026

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Apr 1, 2026

rustbot added T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. labels Apr 1, 2026