diff options
| author | bors <bors@rust-lang.org> | 2024-01-30 05:10:11 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2024-01-30 05:10:11 +0000 |
| commit | 5c9c3c7871d603ba13d38372830eca0c9013e575 (patch) | |
| tree | 3a1f054ca6faa5ab009d16cf0a41e30e40fdaad2 /compiler/rustc_parse/src/errors.rs | |
| parent | 5518eaa946291f00471af8b254b2a1715f234882 (diff) | |
| parent | 60f46289cf55759dc474d796edbf9d38cbab86d4 (diff) | |
| download | rust-5c9c3c7871d603ba13d38372830eca0c9013e575.tar.gz rust-5c9c3c7871d603ba13d38372830eca0c9013e575.zip | |
Auto merge of #117925 - kornelski:read-to-oom, r=Amanieu
Handle out of memory errors in io:Read::read_to_end() #116570 got stuck due to a [procedural confusion](https://github.com/rust-lang/rust/pull/116570#issuecomment-1768271068). Retrying so that it can get FCP with the proper team now. cc `@joshtriplett` `@BurntSushi` ---- I'd like to propose handling of out-of-memory errors in the default implementation of `io::Read::read_to_end()` and `fs::read()`. These methods create/grow a `Vec` with a size that is external to the program, and could be arbitrarily large. Due to being I/O methods, they can already fail in a variety of ways, in theory even including `ENOMEM` from the OS too, so another failure case should not surprise anyone. While this may not help much Linux with overcommit, it's useful for other platforms like WASM. [Internals thread](https://internals.rust-lang.org/t/io-read-read-to-end-should-handle-oom/19662). I've added documentation that makes it explicit that the OOM handling is a nice-to-have, and not a guarantee of the trait. I haven't changed the implementation of `impl Read for &[u8]` and `VecDeque` out of caution, because in these cases users could assume `read` can't fail. This code uses `try_reserve()` + `extend_from_slice()` which is optimized since #117503.
Diffstat (limited to 'compiler/rustc_parse/src/errors.rs')
0 files changed, 0 insertions, 0 deletions
