Tracking Issue for more_fallible_allocation_methods
#86942
Comments
Ericson2314
added
C-tracking-issue
|
Not sure where this should go, but it seems strange to me that |
|
Should #91529 be a part of the tracking issue? |
|
Is this issue still going on? Is it OK to add |
|
I have had little time to debug the tiny few failures or #86938 --- it's not that it would take very long, but that switching tasks from what I am usually doing has a mental overhead. Landing that PR is still good, and will help Rust for LInux slightly which I think is very important, so @Xuanwo if you are interested I would be very thankful and appreciative if you might take over that PR, and then add more |
|
I'm sorry I don't have enough time to finish this issue now. Interested contributors, please take over themselves. Existing work could be found at #91559. Thanks for all the help! |
…hout infallible allocation methods As a part of the work for rust-lang#86942 the `no_global_oom_handling` cfg was added in rust-lang#84266, however enabling that cfg makes it difficult to use `Vec`: the `vec!` macro is missing and there is no way to insert or push new elements, nor to create a `Vec` from an iterator (without resorting to `unsafe` APIs to manually expand and write to the underlying buffer). This change adds `try_` equivalent methods for all methods in `Vec` that are disabled by `no_global_oom_handling` as well as a `try_vec!` as the equivalent of `vec!`. Performance and implementation notes: A goal of this change was to make sure to NOT regress the performance of the existing infallible methods - a naive approach would be to move the actual implementation into the fallible method, then call it from the infallible method and `unwrap()`, but this would add extra compare+branch instructions into the infallible methods. It would also be possible to simply duplicate the code for the fallible version - I did opt for this in a few cases, but where the code was larger and more complex this would lead to a maintenance nightmare. Instead, I moved the implementation into an `*_impl` method that was then specialized based on a new `VecError` trait and returned `Result<_, VecError>`, this trait also provided a pair of methods for raising errors. Never (`!`) was used as the infallible version of this trait (and always panics) and `TryReserveError` as the fallible version (and returns the correct error object). All these `VecError` method were marked with `#[inline]`, so after inlining the compiler could see for the infallible version always returns `Ok()` on success (and panics on error) thus the `?` operator or `unwrap()` call was a no-op, and so the same non-branching instructions as before are generated. I also added `try_from_iter` and `try_expand` methods for completeness, even though their infallible equivalents are trait implementations.
|
The feature tracked by this issue never got merged. I'll close the tracking issue since this is not tracking any work at the moment, but we can reopen (or create a new one) if someone picks this back up in the future. |
Feature gate:
#![feature(more_fallible_allocation_methods)]This is a tracking issue for adding more fallible allocation methods, i.e. ones where allocation failure will return
Err(_)rather than calling some diverging global handler.It overlaps a bit with #32838, since the most general methods will be fallible and allocator-agnostic.
Public API
Basically, all the methods in the
alloccrate that begin withtry_. Perhaps others instdsomeday.Steps / History
alloc: add some try_* methods Rust-for-Linux needs #86938vec: add try_* methods and a try_vec! macro to make Vec usable in without infallible allocation methods #95051RawVec's, to avoid combinatorial explosion.Unresolved Questions
Iteration with no_global_oom_handling adding in alloc: Add unstable Cfg feature `no_global_oom_handling #84266, proposed to be turned to a feature in RFC: fallible-allocation rfcs#3140
Put methods on other type / in other location to avoid
try_prefix (which is sort of an ad-hoc namespacing trick).The text was updated successfully, but these errors were encountered: