Implement From<TryReserveError> for io::Error

[nvzqz]

The try_reserve methods may be called when allocating for I/O.

[rust-highfive]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs to request review from a libs-api team reviewer. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[rust-highfive]

r? @m-ou-se

(rust-highfive has picked a reviewer for you, use r? to override)

[nvzqz]

r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs

[m-ou-se]

I feel somewhat similar about this as I did about #96104, although mapping TryReserveError to io::ErrorKind::OutOfMemory seems more obvious and universally correct.

I wonder if CapacityOverflow should map to OutOfMemory as well, instead of InvalidInput. CapacityOverflow usually means you're trying to allocate even more than could possibly be allocated, which arguably still fits within the 'out of memory' category.

[m-ou-se]

Note that this involves a double allocation, effectively a Box<Box<dyn io::Error>>.

[nvzqz]

I didn't realize io::Error::new was a double-allocation! I wonder if thin dyn box would solve that.

[m-ou-se]

Even worse: if you pass it a string literal ( Error::new(kind, "...")) you get a triple allocation (and a strcpy/memcpy) as the inner box will contain a String.

ThinBox can save one allocation here. I think that'd be a simple change to make, but there might be some non-obvious pitfall.

[m-ou-se]

See #83352

[nvzqz]

I agree with yours and @dtolnay's points in #96104. I think io::Error gets too often used as a catch-all and thus the value exposed at such a generic point (From impl) may be too ambiguous.

[dtolnay]

Since you agree with #96104 (comment), the same point definitely applies to this impl too so I'll close the PR. Thanks anyway!