RFC: fallible-allocation

[maurer]

Move infallibly allocating alloc and std library functions behind a feature, as an extension/stabilization of no_global_oom_handler.

This RFC is specifically not looking to add any new fallible interfaces; those can be handled separately.

Rendered

CCing known interested parties:
@Ericson2314 @joshtriplett @Manishearth

[Manishearth]

cc @rust-lang/libs

[guswynn]

Doesn't this mean that if you ever use a crate that doesn't specify default-features = false for alloc/std you may suddenly have default-features enabled?

I just tested this crate layout:

fn_under_default_feature:
src.rs:

[cfg(feature = hmm)]
pub fn hmm() {}

cargo.toml:

...
[features]
default = ["hmm"]
hmm = []

If I have a crate depend on this with default-features = false, I correctly can't use hmm, but if I add this crate to my downstream crate:
cargo.toml:

[dependencies]
fn_under_default = { path = "../fn_under_default" } # note no `default-features`

In my downstream crate, I can suddenly import and use the hmm fn

Does this mean that someone trying to use alloc = { default-features = false } can accidentally add a crate that doesn't specify turning off the default features and the compiler will longer protect them?

[guswynn]

In the [no_std] case you suddenly will try to link std in (I think) and fail to compile (at least in the embedded case, I think), but in this case, you suddenly can access api's right, which you get no warning for?

[Lokathor]

Yes, that is how default features work. There is currently no way to tell cargo "turn this off and keep it off and i don't care if that makes the build fail i want it to stay off no matter what".

[maurer]

Yes. You'll note that this is listed under potential future things to address. This behavior is actually beneficial, because it allow crates to state their compatibility with a restricted API while still being usable in more common environments.

If you're considering using this in an environment where you want to be sure the feature is off in the final product, you could consider removing the full std or full alloc from the sysroot, or using .cargo/config.toml and rustflags to set a custom sysroot containing only restricted libraries.

[guswynn]

Noting it seems reasonable! It's also possible that the kernel/other projects use cargo-guopy to check their deps for unwanted properties

[joshtriplett]

The general concept of infallible_allocation seems sensible. However, I want to point out a forward-compatibility concern with the proposed way of handling this in cargo, which has also applied to previous proposals that suggest the same thing:

If crates start declaring dependencies on std with default-features = false, they'll break if we introduce a new enabled-by-default feature in the future. We'd likely find that we could never add a new default feature.

I think, instead, we'd need to have a syntax to say "default minus infallible_allocations", which would be forwards-compatible.

[Nemo157]

If crates start declaring dependencies on std with default-features = false, they'll break if we introduce a new enabled-by-default feature in the future. We'd likely find that we could never add a new default feature.

The way this is solved in other crates is to move everything behind a feature and make that default on. You can then in the future subset that feature as necessary, and make it activate those new sub-features.

[Nemo157]

As std grows more feature flags this turns into an O(n!) operation, it might be worth thinking about how to mitigate that before adding feature support at all.

[Ericson2314]

The "portability" lint solves this. Features like this which just add items are closed to being able to turn into separate upstream crates (as proposed in the alternatives) which also solves the problem. splitting crates should be thought of as a special case of the portability lint in general, just as https://en.wikipedia.org/wiki/Horn-satisfiability is an easier special case of https://en.wikipedia.org/wiki/Boolean_satisfiability_problem

[maurer]

I was unaware of the portability lint. After reading the portability lint's RFC, it seems like exactly what we'd want here. That would be superior to the extra builds I'm proposing, but as far as I can tell it's not implemented yet. Since the RFC is merged, hopefully we'll get it before an O(n!) feature explosion catches us.

[Ericson2314]

@joshtriplett it would be useful to reform the concept of default features to mean "give me the default features as of x.y.z". That would solve the problem entirely, and I think corresponds to the way people actually use semver most of the time which is "I tested with x.y.z so give me that or any other compatible version".

[Lokathor]

That is much less forward compatible.

Removing a specific feature from the default for your own crate's usage is much better.

Also, a way to "forbid" a feature, at least from a binary, would be nice but not strictly necessary.

[Ericson2314]

@Lokathor What is? How so?

[Lokathor]

Saying "default features for x.y.z" means developers can't add a new on by default feature and you get it automatically. Which would, for example, completely destroy the entire effort this RFC is trying to attempt.

Saying "default features but minus this one feature i know i don't want" lets you remove a specific offending feature without upsetting the ability for new on by default features in the library.

[Ericson2314]

@Lokathor Let my clarify that when I say "default features for x.y.z", i mean not the literal feature set but the interface implied by that. so adding new features does work.

As @Nemo157 says

The way this is solved in other crates is to move everything behind a feature and make that default on. You can then in the future subset that feature as necessary, and make it activate those new sub-features.

My thing would be the equivalent of turning

default = [ "foo, "bar" ]

into

default_x_z_y = [ "foo, "bar" ]
default = [ "default_x_z_y" ]

and then later versions can define default_x_z_y as need be. The trick is the user doesn't need to worry about default_x_z_y but just worries about no default features. We can do similar things for default-features = false too, i.e how the old empty set becomes the new non-empty set. The trick is to realize users refer to names with respect to a fixed version, no with respect to whatever future compatible version the Cargo solver picks.

---

Stepping back a bit, feature sets form a partial order, and when packages are compatible, there should be a partial order homomorphism from the old package's feature sets to the new ones. This accounts for all the scenarios we were imagining. The trick is simply to make defining the partial order relationship as easy as possible because users won't want to think about the math.

---

Stepping back again, none of these issues are unique to the standard library and the RFC at hand; the same problems can block crates.io. I sometimes feel holding Cargo to a higher standard for stdlib crates is holding us back, we should other make Cargo better for everyone, or not let this stuff get in the way of making Cargo and the standard library rely on each other more.

[Amanieu]

I feel that this should be implemented as a lint rather than messing with Cargo features. Fundamentally this is about enforcing a form of code style ("don't use infallible allocation") rather than working around a missing OS feature ("my target doesn't have a memory allocator").

[Manishearth]

@Amanieu

I feel that this should be implemented as a lint rather than messing with Cargo features. Fundamentally this is about enforcing a form of code style ("don't use infallible allocation") rather than working around a missing OS feature ("my target doesn't have a memory allocator").

Is it? I can imagine, over time, some stdlib features getting dual support for alloc and no-alloc, where they still work without allocations but perhaps not as efficiently.

[programmerjake]

@Amanieu

I feel that this should be implemented as a lint rather than messing with Cargo features. Fundamentally this is about enforcing a form of code style ("don't use infallible allocation") rather than working around a missing OS feature ("my target doesn't have a memory allocator").

Is it? I can imagine, over time, some stdlib features getting dual support for alloc and no-alloc, where they still work without allocations but perhaps not as efficiently.

sorting would be a good example --- some algorithms need extra memory (e.g. merge sort), others can work in-place (e.g. quick sort).

[Amanieu]

We already have a split for alloc/no-alloc: everything that requires allocation is in alloc, while everything that doesn't is in core.

[Manishearth]

We already have a split for alloc/no-alloc: everything that requires allocation is in alloc, while everything that doesn't is in core.

No, I'm talking about things that can work with a split at an implementation level. libstd has many things which also need allocations, but I wouldn't be surprised if some of it could be implemented less efficiently without alloc.

This RFC is for libstd, not just core.

[matklad]

It's unclear to me which parts of std would actually be usable without infallible_allocation. I have a suspicion that almost everything useful in std actually requires allocation? For example, every syscall which uses Path needs to allocate to convert OsString to something the OS can use (appending \0 on Linux, utf-16 encoding on windows). But maybe we can hack around that with adding an io::ErrorKind::BadAlloc?

To be clear, I don't want to get into specifics in this thread, but it would be useful if RFC contained some kind of a table which, for each std module, classified it as "just works", "needs minor API additions", "needs major API additions/redesign". That way, the readers can imagine what std with fallible alloc looks like.

[maurer]

I don't think a ton of std would remain available in the immediate aftermath of this feature. Part of the point is to highlight small gotchas (e.g. Path to OsString conversion) which could be remedied without much work. In cases where a io::Result is already returned, adding an io::ErrorKind::BadAlloc seems like it could improve things even in the normally-infallible case, and since io::ErrorKind is non-exhaustive, no APIs would actually be broken.

If you think it would be useful to go through and annotate I can do that. I would have to do that eventually anyways to actually implement the feature split, so I can try doing the feature split and add to the RFC a summary of what would land on what side of the split, and how easy it would be to move things to out from under the feature.

[jstarks]

If you start returning BadAlloc from something that previously could only fail on a precondition violation, then you have introduced a breaking change to the API contract: previously, callers could assume that if the preconditions held, then the function succeeded.

Callers that use unwrap on the result in this case will not see a behavior change (at least if they are using panic=abort...), but callers that are ignoring the result will get silent behavior changes under low resource conditions. This could introduce security bugs into what is today correct code.

See related discussion around rust-lang/rust#84612, e.g. rust-lang/rust#84612 (comment).

A possible counterargument is that (on most OSes?), most syscalls that take strings are fallible, so at least for the PathBuf -> CString case, callers that ignored the result of such calls were already broken.

I suppose one option would be to only return BadAlloc when infallable_allocations was opted out. Then if your crate opts out of this feature, you must not only use only fallible versions of allocating APIs, but you must ensure your code treats all APIs returning io::Error as possibly fallible. This might also provide a solution for the above linked issue.

[Manishearth]

I suppose one option would be to only return BadAlloc when infallable_allocations was opted out

I believe that is indeed the proposal

[maurer]

For functions returning io::Result, I was in fact suggesting we could change these functions to return BadAlloc in the general case. These functions are not ones where you can assume the success arm of the Result because you have provided "good" arguments - IO can fail in a variety of ways outside your program that you don't have control over.

I agree that it is not necessarily the case that already returning a bool/Option/Result implies that BadAlloc can be safely added as an error condition, especially in the case described above where a user might have been using a documented statement on how the function can fail.

However, I think this should be a separate discussion, not for this RFC. This RFC only adds the distinction between infalliable_allocations and non-infallible interfaces. I'm intentionally leaving the details of how the new interfaces should look to future discussion, because that is also a complex issue that deserves discussion, and may differ for things which today return io::Result vs other situations.

[yaahc]

I've nominated this RFC for discussion in the next @rust-lang/libs-api meeting. Here are my notes and questions from my review of the RFC / comments so far:

• Is there any reason to not expose this configuration via feature flagging?
  • Amanieu: Can this instead be implemented as a lint?
    • Manishearth: Doing it as a lint will preclude creating alternative versions for the same functions that work less efficiently but don't allocate in order to preserve more of the API when infallible allocation is disabled.
      • Do we want alternative impls of the same functions for with/without fallible allocation? Why not just create an alternative version that exposes the allocation failure rather than silently introducing a less efficient version of the same function?
• How badly will users of this configuration need the ability to ban specific features from being enabled at all?
  • guswynn: probably not urgent, can be enforced with cargo-guppy
• Nemo157: Does this mean we need to implement the portability lint more urgently?
  • Does this RFC's implementation need to be blocked on the portability lint existing? Likely not, this will only become an issue once we've got a large number of features.
• While this is unstable, is there any reason to block implementing this RFC on the forward compatibility concerns around default features?

How do we want to resolve the enabled by default feature forward compatibility issue? Proposals:

• Nemo157: feature flag all of std and subset it in the future when we need to add new features
• Erikson2314: Create alias features for sets of defaults.
• joshtriplett: Create a syntax for disabling individual default features but leaving the rest of the defaults on.

Do the latter two solutions even solve the issue around not being able to add new default features? Why can't you still use default-features = false and end up with the same issues around not being able to move any existing APIs behind a new enabled by default feature flags? It seems like the latter two solutions also implicitly ban the usage of default-features = false for sysroot crates.

[jstarks]

However, I think this should be a separate discussion, not for this RFC. This RFC only adds the distinction between infalliable_allocations and non-infallible interfaces. I'm intentionally leaving the details of how the new interfaces should look to future discussion, because that is also a complex issue that deserves discussion, and may differ for things which today return io::Result vs other situations.

I agree, the question of the precise interfaces is separable. But I think there's a question to be answered now, too--what's the process for marking APIs as in the safe-for-fallible set? Is it opt-in or opt-out? I believe currently whether an API in the alloc or std crates actually allocates is an implementation detail. The existence of this feature will make it contractual--APIs available without the infallible_allocations feature must either:

• Not allocate
• Allocate but have fallback behavior when allocation fails
• Report allocation failures via Result

And they must preserve this behavior for all time. This may not always be desirable, even if a function does not currently allocate.

Similar to const fn, perhaps is something that would need to be considered and stabilized on a per-function basis. And by default all functions would need to be considered out of scope for infallible_allocations.

[Ericson2314]

How do we want to resolve the enabled by default feature forward compatibility issue?

I am thinking of opening a Cargo RFC about that problem. I figure having two separate technical discussions is better since the deficiency with Cargo features is in no way specific to this RFC or the standard library. The final policy decision of course will depend on both, but I still think separate threads will probably be more manageable.

[Manishearth]

@maurer Out of curiosity, how well does the portability lint address your use case? I do feel like feature flagging is the better option here, but it's probably worth comparing the two.

[Ericson2314]

@Manishearth I don't see why they would be mutually exclusive.

• The portability lint ought to work on arbitrary cfg formulae, so it is useful to catch errors without 2^n rebuilds whether or not we use ad-hoc cfg tokens or Cargo features.
• Cargo features are useful to mediate feature needs between dependencies. ad-hoc cfg tokens simply don't have any mechanism for that, so it would be very hard to foster a "no global OOM handing" ecosystem the way we fostered a "no std" ecosystems.

It thus seems clear to me that one wants both. The real alternative is cfg vs separate crate. Because separate crate both avoids the 2^n problem (crate boundaries are enforced like the portability lint would) and supported by Cargo (basic deps, simpler than features).

[Manishearth]

@Ericson2314 Yeah, that's fair! To be clear; I wasn't 100% sure on how the portability lint fits in here, but also I hadn't seen it addressed in the thread so I asked. That's useful context, thanks!

[joshtriplett]

We discussed this in today's @rust-lang/libs-api meeting.

We didn't have any objections in principle to the concept of this.

Our biggest concern was the stability guarantees around these feature flags; we're very concerned about ending up with unexpected breakage when trying to add or modify feature flags over time. If we can address that, such as by ensuring that this can only be used on a nightly toolchain, then we'd be in favor of enabling experimentation here.

We need to see a plan for how that could potentially work. (There are several such proposals in this thread; we just need to see a concrete proposal to use one of them that's capable of meeting our stability requirements, and that for now would keep this exclusive to nightly.)

[Lokathor]

build-std is itself unstable, so this would automatically also be unstable until at least then, right?

[the8472]

build-std is itself unstable, so this would automatically also be unstable until at least then, right?

The issue is that build-std may be stabilized while a big feature like fallible allocation still needs time to bake as unstable.

[Lokathor]

Right, it's not a permanent solution, just a stop-gap.

[Manishearth]

Hmm, I'm actually hitting a similar issue in -Zbuild-std where we need a way for users of -Zbuild-std to globally opt in to a Rust feature flag imposed by libstd: rust-lang/wg-cargo-std-aware#69

In that situation, -Zbuild-std on certain platforms requires a feature flag for every use of std::. I think we might want something similarly shaped here, but as in that situation, provide a global opt in so that you don't have to patch your dependencies. Perhaps -Zstd-cfg-fallible-allocations or something

[inquisitivecrystal]

The general concept of infallible_allocation seems sensible. However, I want to point out a forward-compatibility concern with the proposed way of handling this in cargo, which has also applied to previous proposals that suggest the same thing:

If crates start declaring dependencies on std with default-features = false, they'll break if we introduce a new enabled-by-default feature in the future. We'd likely find that we could never add a new default feature.

I think, instead, we'd need to have a syntax to say "default minus infallible_allocations", which would be forwards-compatible.

Okay, possibly silly comment: why don't we make a general syntax to say "don't enable this specific feature, even if it's part of default"? It's always felt like a big hole to me that to opt out of even one default feature, you have to opt out of all of them, absent the library being specifically designed to deal with the situation. I know you can always work around that by manually enabling them, but then you bump into the same problem we do here.

[yaahc]

Okay, possibly silly comment: why don't we make a general syntax to say "don't enable this specific feature, even if it's part of default"? It's always felt like a big hole to me that to opt out of even one default feature, you have to opt out of all of them, absent the library being specifically designed to deal with the situation. I know you can always work around that by manually enabling them, but then you bump into the same problem we do here.

Not a silly comment. I think this is definitely a possible option we could go for and should be considered as an option in the RFC/Plan for how we can resolve the forward compatibility concern around std feature flags.

[programmerjake]

how about features = ["!fallible-allocation"] as the new syntax for opting-out of features? There could also be a option in std's Cargo.toml that disallows using default-features = false, requiring users to explicitly list all features they wish to opt-out of.

[Ericson2314]

Opting out is no solution. Now if someone else adds a regular optional feature, well that's getting dragged in to. And say that new feature depend on the one you opted out of!

[programmerjake]

Opting out is no solution. Now if someone else adds a regular optional feature, well that's getting dragged in to. And say that new feature depend on the one you opted out of!

opting out of features could be transitive, where if feature a depends on feature b, opting out of feature b would also opt out of feature a. cargo would error if you explicitly opt-in for a feature that was directly or transitively opted-out of.

[Ericson2314]

@programmerjake that would mean it becomes a breaking change to add dependencies between existing features, because that means opt-outs can turn off more features than before.

Thinking about comparability is hard enough without allowing negative reasoning.

[programmerjake]

@programmerjake that would mean it becomes a breaking change to add dependencies between existing features, because that means opt-outs can turn off more features than before.

but adding dependencies is already a breaking change if you have feature a which is changed to depend on feature b and you want feature a but require feature b to not be enabled (e.g. feature b could depend on std on a no_std target).

making it so opting out of feature b automatically disables feature a isn't that different -- you would still not be able to use feature a without feature b after the breaking change.

[Ericson2314]

@programmerjake It's really important to distinguish between:

• Cargo failing to find a solution with the new version where it did before
• Cargo finding a solution with the version that fails to build

Only the latter is a real breaking change. The former is still unfortunate, but allows the solver to do it's job keeping the user's build working.

Today it is impossible to force off a feature in dependency specifications, and I even believe it is disallowed in the workspace root, so you would just get a std feature which would fail to build. But if we could express that the std feature isn't buildable without some platform functionality, then it would squarely be the second case: a solver failure saying something like foo -> std -> cfg(any(target_os = "linux", target_os = "windows", target_os = "macos")), the last of which is not met.

With your thing, however, would loose features you always had before, which would trigger a build failure, the second case.

[programmerjake]

@programmerjake It's really important to distinguish between:

• Cargo failing to find a solution with the new version where it did before
• Cargo finding a solution with the version that fails to build

Only the latter is a real breaking change. The former is still unfortunate, but allows the solver to do it's job keeping the user's build working.

I disagree, both are breaking changes:

so are you saying cargo will automatically move to an older version of the package if it fails to find a solution with the newer version? that's news to me.

If cargo doesn't automatically move to an older version, it's still a breaking change since if cargo can't solve the features it will fail to build, breaking previously working code -- just failing before running rustc instead of while running rustc.

If cargo automatically moves to an older version, I'd still consider it a breaking change since cargo silently ignores the new version, which may fix critical bugs, even if the version number is compatible, making it very user-unfriendly.

Today it is impossible to force off a feature in dependency specifications, and I even believe it is disallowed in the workspace root, so you would just get a std feature which would fail to build. But if we could express that the std feature isn't buildable without some platform functionality, then it would squarely be the second case: a solver failure saying something like foo -> std -> cfg(any(target_os = "linux", target_os = "windows", target_os = "macos")), the last of which is not met.

With your thing, however, would loose features you always had before, which would trigger a build failure, the second case.

no, if you declare the features you depend on then the solver will error after that broken crate made a breaking change. they only get silently disabled if you were depending on the feature being enabled by default, rather than explicitly naming it or some feature that transitively depends on it.

In any case, the problem is caused by the crate making the breaking change but not correctly reflecting that in the version number.

[Ericson2314]

I am going to finish writing my counter-proposal soon and I think it would be better to discuss that there. It is rather off topic here.

[Ericson2314]

My proposal is up: #3146