impl From<TryReserveError> for io::Error

[kornelski]

There's an obvious mapping between these two errors, and it makes I/O code less noisy.

I've chosen to use simple ErrorKind::OutOfMemory io::Error, without keeping TryReserveError for the source(), because:

• It matches current uses in libstd,
• ErrorData::Custom allocates, which is a risky proposition for handling OOM errors specifically.
• Currently TryReserveError has no public fields/methods, so it's usefulness is limited. How allocators should report errors, especially custom and verbose ones is still an open question.

Just in case I've added note in the doccomment that this may change.

The compiler forced me to declare stability of this impl. I think this implementation is simple enough that it doesn't need full-blown stabilization period, and I've marked it for the next release, but of course I can adjust the attribute if needed.

[rustbot]

r? @cuviper

rustbot has assigned @cuviper.
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

[cuviper]

Since such impls are insta-stable...
@rustbot label -T-libs +T-libs-api
r? libs-api

[dtolnay]

Thanks!

[dtolnay]

@rust-lang/libs-api:
@rfcbot fcp merge

The standard library changes in this PR illustrate how this impl is useful, in particular when using try_reserve inside the implementation of std::io::Read::read_to_end or std::io::Read::read_to_string.

[rfcbot]

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[the8472]

TryReserveError has two TryReserveErrorKind, one is for capacity overflow and one is for an allocation failure.
I'd say the former is more like EOVERFLOW than ENOMEM.

Currently TryReserveError has no public fields/methods, so it's usefulness is limited.

It does have kind. Sure, that's unstable, but eventually it'll probably be stabilized.

[kornelski]

There's no EOVERFLOW equivalent in ErrorKind, not even in the expanded #106375.

As far as I can tell, EOVERFLOW is mainly used to report accessing >4GB files using 32-bit APIs, when there is valid data to return, it just doesn't fit the API. CapacityOverflow is not quite the same case. I don't expect POSIX implementations to have a special case for malloc(isize_max), and they'd likely report ENOMEM in all cases.

I believe that the current shape of TryReserveErrorKind is only a byproduct of RawVec internals, and the OOM handling and allocator APIs being unfinished, and may not survive as-is when they're done.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[the8472]

As far as I can tell, EOVERFLOW is mainly used to report accessing >4GB files using 32-bit APIs, when there is valid data to return, it just doesn't fit the API

It's also used to indicate that offset calculations exceed size_t. E.g. sendfile() returns EOVERFLOW when you try to use an offset + count that's beyond what's addressable by file offsets.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[dtolnay]

Looks good. Thank you!

I think ErrorKind::OutOfMemory is all right as the mapping of TryReserveErrorKind::CapacityOverflow, but if there is agreement that a different io error kind is better for it, I am confident we can follow up on that afterward without breaking anybody's code.

[dtolnay]

@bors r+

[bors]

📌 Commit aa581f0 has been approved by dtolnay

It is now in the queue for this repository.

[Nadrieril]

@bors rollup