Move std::io::RawOsError to core::io

[bushrat011899]

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

Description

As a part of moving components of std::io into alloc::io and core::io, there will need to be a new home for the type RawOsError. In this PR, I propose moving it to core::io, and removing it from std::sys. I suspect this will be quite controversial as it is a platform dependent type, but this is not the only instance of a type being conditioned on target_os in core (e.g., core::os and core::ffi).

Since RawOsError is currently unstable, I think it's reasonable to make this move now, and worry about making it platform independent if/when it is stabilized (e.g., replacing it with a wrapper around isize on all platforms).

---

Notes

• No AI tooling of any kind was used during the creation of this PR.

[rustbot]

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 7 candidates
• Random selection from Mark-Simulacrum, jhpratt

[lygstate]

lgtm

[Mark-Simulacrum]

@joboet, do you think we should replicate the sys/ structure in core for platform-specific things, following the convention in std (IIRC linted on by tidy at least to some extent as well).

r? joboet

r=me if we don't hear back in a week or so (can always change this later).

[rustbot]

joboet is not on the review rotation at the moment.
They may take a while to respond.

[joboet]

It depends: having a separate sys module is useful for std as it forces its abstractions to conform to a shared interface and makes it easier to document. If we expect core to contain a significant number of abstractions, then I'd say having a dedicated sys module makes sense. But if it's just RawOsError alone then I don't think the added complexity is justified.

[bushrat011899]

It depends: having a separate sys module is useful for std as it forces its abstractions to conform to a shared interface and makes it easier to document. If we expect core to contain a significant number of abstractions, then I'd say having a dedicated sys module makes sense. But if it's just RawOsError alone then I don't think the added complexity is justified.

For some added context, #152918 and #154684 have done a little scouting as to the extent of changes required. I believe the only other items which may need to be moved to core are IoSlice and IoSliceMut. Technically, io::Error will include configuration to switch between bitpacked and unpacked internal representations, but that's currently internal to std::io::error anyway.

[Mark-Simulacrum]

Alright, let's move forward with this and revisit if we end up with much more than a few cfgs (and maybe even when those spread outside error).

@bors r+

[rust-bors]

📌 Commit 7653e5e has been approved by Mark-Simulacrum

It is now in the queue for this repository.