-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
impl From<TryReserveError> for io::Error #121403
Conversation
Since such impls are insta-stable... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
@rust-lang/libs-api: The standard library changes in this PR illustrate how this impl is useful, in particular when using try_reserve inside the implementation of |
Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members: 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. |
It does have |
There's no As far as I can tell, I believe that the current shape of |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
It's also used to indicate that offset calculations exceed |
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
@bors r+ |
@bors rollup |
Rollup of 8 pull requests Successful merges: - rust-lang#99153 (Add Read Impl for &Stdin) - rust-lang#114655 (Make `impl<Fd: AsFd>` impl take `?Sized`) - rust-lang#120504 (Vec::try_with_capacity) - rust-lang#121280 (Implement MaybeUninit::fill{,_with,_from}) - rust-lang#121403 (impl From<TryReserveError> for io::Error) - rust-lang#121526 (on the fly type casting for `build.rustc` and `build.cargo`) - rust-lang#121584 (bump itertools to 0.12) - rust-lang#121711 (Implement junction_point) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#121403 - kornelski:io-oom, r=dtolnay impl From<TryReserveError> for io::Error 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.
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 keepingTryReserveError
for thesource()
, because:ErrorData::Custom
allocates, which is a risky proposition for handling OOM errors specifically.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.