Move std::io::ErrorKind to core::io#154654
Conversation
|
rustbot has assigned @Mark-Simulacrum. Use Why was this reviewer chosen?The reviewer was selected based on:
|
This comment has been minimized.
This comment has been minimized.
6acf3fc to
0c00e70
Compare
This comment has been minimized.
This comment has been minimized.
0c00e70 to
a87a02a
Compare
This comment has been minimized.
This comment has been minimized.
8faa574 to
0ef55d6
Compare
This comment has been minimized.
This comment has been minimized.
0ef55d6 to
3e16c8b
Compare
This comment has been minimized.
This comment has been minimized.
3e16c8b to
56dfe2e
Compare
This comment has been minimized.
This comment has been minimized.
56dfe2e to
aa24135
Compare
This comment has been minimized.
This comment has been minimized.
aa24135 to
f25b166
Compare
This comment has been minimized.
This comment has been minimized.
94753ea to
b0ce24e
Compare
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. |
|
looks good to me |
…r=Mark-Simulacrum Move `std::io::ErrorKind` to `core::io` ACP: rust-lang/libs-team#755 Tracking issue: rust-lang#154046 Related: rust-lang#152918 ## Description I consider rust-lang#154046 to be really important for `no_std`, but I'm concerned rust-lang#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!
Rollup of 6 pull requests Successful merges: - #154654 (Move `std::io::ErrorKind` to `core::io`) - #155054 (constify `Index(Mut)`, `Deref(Mut)` for `Vec`) - #155507 (suggest expect instead of unwrap when arg provided) - #154664 (core/num: Implement feature `integer_cast_extras`) - #155474 (Rename incremental `cfail`/`cpass` revisions to `bfail`/`bpass`) - #155493 (docs(num): fix stale link to `mem::Alignment`)
|
This pull request was unapproved. This PR was contained in a rollup (#155534), which was unapproved. |
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`
74d5469 to
fe2b39f
Compare
|
@rustbot ready |
|
@bors try jobs=aarch64-msvc-1 |
This comment has been minimized.
This comment has been minimized.
Move `std::io::ErrorKind` to `core::io` try-job: aarch64-msvc-1
|
@bors r=Mark-Simulacrum No worries about the little mistakes btw, these are very common and there's not much you can do to prevent them :3 |
…uwer Rollup of 11 pull requests Successful merges: - #154654 (Move `std::io::ErrorKind` to `core::io`) - #145270 (Fix an ICE observed with an explicit tail-call in a default trait method) - #154895 (borrowck: Apply `user_arg_index` nomenclature more broadly) - #155213 (resolve: Make sure visibilities of import declarations make sense) - #155346 (`single_use_lifetimes`: respect `anonymous_lifetime_in_impl_trait`) - #155517 (Add a test for Mach-O `#[link_section]` API inherited from LLVM) - #155549 (Remove some unnecessary lifetimes.) - #154248 (resolve : mark repr_simd as internal) - #154772 (slightly optimize the `non-camel-case-types` lint) - #155541 (Add `#[rust_analyzer::prefer_underscore_import]` to the traits in `rustc_type_ir::inherent`) - #155544 (bootstrap: Make "detected modifications" for download-rustc less verbose)
Rollup merge of #154654 - bushrat011899:core_io_error_kind, r=Mark-Simulacrum Move `std::io::ErrorKind` to `core::io` 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!
…uwer Rollup of 11 pull requests Successful merges: - rust-lang/rust#154654 (Move `std::io::ErrorKind` to `core::io`) - rust-lang/rust#145270 (Fix an ICE observed with an explicit tail-call in a default trait method) - rust-lang/rust#154895 (borrowck: Apply `user_arg_index` nomenclature more broadly) - rust-lang/rust#155213 (resolve: Make sure visibilities of import declarations make sense) - rust-lang/rust#155346 (`single_use_lifetimes`: respect `anonymous_lifetime_in_impl_trait`) - rust-lang/rust#155517 (Add a test for Mach-O `#[link_section]` API inherited from LLVM) - rust-lang/rust#155549 (Remove some unnecessary lifetimes.) - rust-lang/rust#154248 (resolve : mark repr_simd as internal) - rust-lang/rust#154772 (slightly optimize the `non-camel-case-types` lint) - rust-lang/rust#155541 (Add `#[rust_analyzer::prefer_underscore_import]` to the traits in `rustc_type_ir::inherent`) - rust-lang/rust#155544 (bootstrap: Make "detected modifications" for download-rustc less verbose)
View all comments
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 withErrorKind, since it can be moved somewhat trivially. It has no dependencies on functionality instd, no platform specific behaviour, and could provide an excellent bridging point forno_stdIO libraries.Since
std::io::ErrorimplementsFrom<ErrorKind>, libraries could write functions which returnResult<T, core::io::ErrorKind>, and therefore be usable instd-using libraries with the?operator. For that reason, I'd consider this to be a worthwhile change even if the rest ofstd::iocouldn't be moved tocore/alloc, and entirely compatible with any efforts to make such a change in the future.Notes