Preventing implicit global OOM handling

[Ericson2314]

The basic issue is that in certain contexts it's deemed very important to enforce that all allocation errors are handled explicitly so there are no unanticipated failure modes. For en example of this, see Linus's response in https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/.

The Rust standard library doesn't help help one keep track of errors, because many functions call the global handle_alloc_error to abort the thread/program. Note that this affects not only functions dealing with allocated data (Box, Vec, etc.), but also more innocent-looking functions like slice::sort, which just allocate temporaries so there's no hint in the type signature.

I would like to see the problem solved, but not in a way that just means such programs ignore alloc and hand-roll their own abstractions, because I think that would result in unnecessary and tragic ecosystem fragmentation.

My tentative plan is just add a enabled-by-default Cargo feature, without which handle_alloc_error and friends simply don't exist. I have started implanting that in https://github.com/rust-lang/rust/pull/84266.

[SimonSapin]

Does Cargo’s build-std support controlling standard library crate features? Does disabling a default feature require doing so in every single crate of a dependency graph? (Since ~everything has implicit dependencies on standard library crates)

[phil-opp]

Standard library features can be set using the -Zbuild-std-features flag (only in combination with -Zbuild-std). It is for example commonly used for enabling the mem feature of compiler_builtins.

Does disabling a default feature require doing so in every single crate of a dependency graph? (Since ~everything has implicit dependencies on standard library crates)

You only need to do it for the root crate since this overwrites the implicit std/core/alloc dependencies directly (and there is only a single version of them that is used for all crates). If any of the dependencies use a disabled feature you would get a compile error (e.g. "method does not exist").

[SimonSapin]

Ah I see. Since it’s a Cargo CLI flag rather than something specified in the Cargo.toml of each crate the "take the union of features requested by all dependents" behavior does not apply. (Requested even implicitly by not opting out of default features. This makes it hard to actually disable a default feature in a library with many dependents.)