Handle OOM when writing to Vec

[a1phyr]

I haven't found any discussion on this, but I think that handling those OOM is desirable.

[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

[marmeladema]

Seems similar to #84612

Cc @kornelski

[kornelski]

IMHO this is a good idea. This is an io type returning io::Error, and users should be treating this API seriously as something that may fail.

It may be worth making this explicit in the documentation that it applies to Vec too.

PR #84612 got postponed in hope that oom=panic will make it unnecessary, but oom=panic is being removed! So the other PR should be revived too.

[rustbot]

This PR was rebased onto a different master 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.

[a1phyr]

The use of these methods will most likely be in generic context anyway, where errors will be properly handled.

[the8472]

Prior PRs that converted things to try_reserve

• Improve several Read implementations #122441
• Handle out of memory errors in io:Read::read_to_end() #117925

[the8472]

We discussed this during today's libs-API meeting. The issue with this is that there's a lot of code out there that assumes that write!(&mut vec, ...) will never error and thus doesn't check the result.
In principle such code is wrong and we would be allowed to break it, but there's too much of it out there and the gain is too small, especially considering that linux systems will only return actually surface the error on enormous allocation requests. We also discussed whether we would retroactively bless this use by guaranteeing that this Write impl will always return Ok() or abort, but that didn't reach a conclusion and would require a separate proposal.

So instead we'll consider this a part of a future fallible-Vec API, something that remains unsolved. E.g. if we ever introduced a vec::fallible::Vec, then its Write impl would use try_reserve.
Until then people can work around this with a wrapper Write type that does call try_reserve before write.

[marmeladema]

We discussed this during today's libs-API meeting. The issue with this is that there's a lot of code out there that assumes that write!(&mut vec, ...) will never error and thus doesn't check the result.

Do we have data to back that claim? Additionally, the return value of write! being a Result, the compiler should already complain in such case since the type is marked as must_use right?
I personally had to explicitly unwrap in all my write! calls in the past so I am fairly surprised by the claim that "a lot of code out there doesn't check the result". Seems like this code must be explicitly ignoring compiler warnings?

[the8472]

We basically looked at code searches, https://github.com/search?q=lang%3ARust+%22_+%3D+write%21%22&type=code

[a1phyr]

How much of this actually uses Vec<u8>? While navigating your link, almost all uses seem to be on String, or stdout/stderr.