Move std::io::Error into core

[bushrat011899]

View all comments

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

Description

Moves std::io::Error into core, deferring Box-adjacent methods to incoherent implementations in alloc, and RawOsError methods to std. This requires some substantial changes to the internals of Error, but none of them are breaking changes or externally visible.

Notably, I've replaced usage of Box with a wrapper around a pointer and an appropriate drop function. This requires the addition of quite a few lines of unsafe, but is required to work around Box only being accessible from alloc. Additionally, an atomic pointer to a VTable is used for working with RawOsError in core, since we cannot know the required implementations without std.

---

Notes

• This PR adopts the VTable technique from Move OS-dependent parts of std::io to alloc #152918
• This PR builds on my previous PR Move std::io::RawOsError to core::io #155574
• No AI tooling of any kind was used during the creation of this PR.

[programmerjake]

example of how to link from core's docs to std: https://doc.rust-lang.org/1.95.0/src/core/str/mod.rs.html#200

[bushrat011899]

example of how to link from core's docs to std: https://doc.rust-lang.org/1.95.0/src/core/str/mod.rs.html#200

That's a clever trick I never knew about! Looks like it's also required for linking to incoherent implementations even within the file that creates them too.

[programmerjake]

label -O-unix
See

maybe just leave it until you get the PR to work, that way there's less comment spam.

[rustbot]

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]

Not sure if I have permission to do this, but I do think it should be run:

@bors try @rust-timer queue

[rust-bors]

@bushrat011899: 🔑 Insufficient privileges: not in try users

[thomcc]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: a2159f2 (a2159f26dc9ea0fbf95f5a88e2c0a393d8fdaab4, parent: 800892799d7666fe1dc17abd862100a6cf273718)

[rust-timer]

Finished benchmarking commit (a2159f2): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	1.0%	[0.6%, 2.8%]	6
Regressions ❌ (secondary)	1.6%	[0.2%, 8.0%]	17
Improvements ✅ (primary)	-0.3%	[-0.5%, -0.2%]	6
Improvements ✅ (secondary)	-4.2%	[-5.9%, -0.0%]	7
All ❌✅ (primary)	0.4%	[-0.5%, 2.8%]	12

Max RSS (memory usage)

Results (primary 3.3%, secondary -2.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.3%	[2.1%, 5.2%]	3
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.1%	[-2.2%, -2.1%]	2
All ❌✅ (primary)	3.3%	[2.1%, 5.2%]	3

Cycles

Results (primary 2.5%, secondary 1.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.5%	[2.5%, 2.5%]	1
Regressions ❌ (secondary)	5.4%	[2.3%, 7.3%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.0%	[-6.0%, -2.9%]	4
All ❌✅ (primary)	2.5%	[2.5%, 2.5%]	1

Binary size

Results (primary 0.5%, secondary 1.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.8%	[0.3%, 1.7%]	26
Regressions ❌ (secondary)	1.4%	[0.0%, 1.7%]	91
Improvements ✅ (primary)	-0.8%	[-3.6%, -0.1%]	7
Improvements ✅ (secondary)	-3.6%	[-7.3%, -0.9%]	8
All ❌✅ (primary)	0.5%	[-3.6%, 1.7%]	33

Bootstrap: 507.838s -> 512.25s (0.87%)
Artifact size: 398.10 MiB -> 398.11 MiB (0.00%)

[bushrat011899]

I invite anyone with more experience interpreting a perf run to help me out here, but below is my best attempt at understanding these results. From what I can tell, there is no measurable difference in runtime performance, despite the following two changes which could impact runtime:

1. Use of an static atomic pointer VTable for information (debug string, error kind, etc.) about OS error codes.
2. Storing drop function pointers on the heap for custom error types stored within Error.

However it's possible runtime performance along codepaths affected by this PR isn't being measured by the current set of benchmarks. After all, the worst performance is likely to be seen in dropping Error and/or debug printing OS error codes as Error. Since these are both in the failure path for a crate, I consider this acceptable.

Out of the primary compilation benchmarks, it appears the worst regressions come down to spending more time in LLVM optimising, or more time in rustc handling the incoherent methods on Error. I will revisit my use of incoherence to see if I can reduce it, but I'm uncertain if there's much that can be done with regards to LLVM optimisation time. I suspect it comes from needing to work harder around the heap allocated VTable when dropping and atomic operations when creating/printing an Error from an OS error code.

@rustbot label: +perf-regression-triaged