Tracking Issue for `more_fallible_allocation_methods`

[Ericson2314]

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 alloc crate that begin with try_. Perhaps others in std someday.

Steps / History

• Implementation:
  • alloc: add some try_* methods Rust-for-Linux needs  #86938 vec: add try_* methods and a try_vec! macro to make Vec usable in without infallible allocation methods #95051
  • more to come probably
  • Might consider removing less general methods that are unstable, such as RawVec's, to avoid combinatorial explosion.
• Final comment period (FCP)
• Stabilization PR

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).

[leo60228]

Not sure where this should go, but it seems strange to me that try_reserve was stabilized in 1.57 but Box::try_new is still unstable.

[TennyZhuang]

Should #91529 be a part of the tracking issue?

[Xuanwo]

Is this issue still going on? Is it OK to add try_ alike API in alloc? I'm interested to send PRs around this feature.

[Ericson2314]

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 try_ building upon it.

[Xuanwo]

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!