allocator: refactor for stabilisation

[nia-e]

View all comments

Adds my current proposal per the doc in #156882 and follow-up Zulip conversations (notably for dyn-compat) unstably.

r? libs

[nia-e]

Note that the no-panic bounds introduced close #156490 and #155746. However, if we want to relax them in the future, we may need to adjust our collection types to be more resilient.

[clarfonthey]

This guarantee seems fine on the surface, but I'm trying to wrap my head around what's actually being guaranteed here. Like, clearly, it'd be wildly unsafe to offer an invalidate_everything method on an allocator that just deletes the backing memory without requiring any of the things that are using it to be dropped, but this feels like it's opening the door for that kind of method "as long as you're careful" which, doesn't make a lot of sense.

Like, I'm trying to gauge what value is being gained by this guarantee and it mostly just feels like it's making things more confusing without actually helping.

View changes since the review

[nia-e]

we're saying that such an invalidate_everything method is allowed to exist, and you can't rely on the allocator having not yet been dropped for soundness. in other words, so long as you hold a &alloc (thus preventing a &mut alloc from being created), you can trust the memory you have is fine; but if you lose the &alloc and get a new one back, your memory might have been scribbled over and you must act as such

[clarfonthey]

Okay, but wouldn't that be the same thing as the lifetime expiring as before? Technically, even though both of them are written as &A, you've gotten a new &A lifetime in that case.

[nia-e]

i think the extra guarantee here is that if you do hold a &mut alloc, you can call methods that take alloc by-shared-ref without worry but you can't pass the actual &mut to an untrusted function and expect your allocator to be okay at the end. but i agree that's not obviously guaranteed

[clarfonthey]

Isn't that just totally breaking the aliasing guarantees, though? Since that &mut reference wouldn't be unique.

[nia-e]

...you know, you make a good point. i'll revisit the reasoning for this, i recall adding this in response to something being brought up

[nia-e]

nvm, i'm being stupid. the following is the reason:

let mut alloc = SomeAllocator::new();
let ptr = alloc.allocate(...);
alloc.something_by_shared_ref();
// ptr is still guaranteed to be valid
alloc.trusted_method_by_unique_ref();
// ptr is still valid because we know for sure the method is trusted not to mess w/ allocator state
alloc.untrusted_method_by_unique_ref();
// ptr must be assumed to be maybe-invalid even if the lifetime of alloc is not expired and ptr hasn't yet been deallocated

[clarfonthey]

I guess that I was technically thinking of Box whose lifecycle is intrinsically tied to the lifetime of the allocator parameter, whereas in this case if you just call alloc and dealloc manually the "lifetime" is not really tracked at all. So, yes, mutable borrows can happen on the allocator and it's fine, and you guarantee this doesn't happen by taking a non-mutable borrow.

[clarfonthey]

Seeing this thread from @RalfJung: #157428 (comment)

I think we probably also need to be careful about how we define the relationship between these rules and StaticAllocator, since "lifetime expiration" in those cases refers to the allocator value and not references in that case.

[clarfonthey]

@rustbot author

(mostly so you can more clearly signal when you think things are ready; I've commented here already so I'll see any additional changes for review as they're made)

[nia-e]

I dropped the 'static bound here (and thus implicitly in Box::pin_in, etc.); since this trait is about being able to be lifetime-subtyped safely, it would mean that you need to be able to coerce to a StaticAllocator + 'a so the whole guarantee about "this is Actually Static I Promise" has weight. cc @rust-lang/opsem in case i did a bad here

View changes since the review

[RalfJung]

That's more of a @rust-lang/types question

[RalfJung]

Note that there's also the default error hook defined in liballoc, which panics. This can obviously unwind, and it can even invoke arbitrary user-defined code via a custom #[panic_handler]. Maybe that should be changed to a non-unwinding panic.

[RalfJung]

Never mind, that is already using a non-unwinding panic.

rust/library/alloc/src/alloc.rs

Lines 572 to 577 in 4294891

	pub unsafe fn __rdl_alloc_error_handler(size: usize, _align: usize) -> ! {
	core::panicking::panic_nounwind_fmt(
	format_args!("memory allocation of {size} bytes failed"),
	/* force_no_backtrace */ false,
	)
	}

And setting a custom #[alloc_error_handler] is unstable. So we should be good on that front.

[maxdexh]

What about allocators panicking in their drop?

[clarfonthey]

Never mind, that is already using a non-unwinding panic.

Note: this is why I mentioned that the status quo is always an abort, since libstd uses this handler as well.

What about allocators panicking in their drop?

I could have sworn that panics in destructors were always converted to unconditional aborts, but I can't find any link in the reference that says this. At least, panics in destructors are risky because they're run during unwinding, and a panic while unwinding is always an abort.

There is pretty strong justification for wanting an unwinding alloc_error_handler because it allows recovering from OOM conditions in some cases, but it also comes with a lot of potential footguns, at least similar to mutex poisoning and the like.

[RalfJung]

I could have sworn that panics in destructors were always converted to unconditional aborts, but I can't find any link in the reference that says this. At least, panics in destructors are risky because they're run during unwinding, and a panic while unwinding is always an abort.

The RFC didn't make it (yet): rust-lang/rfcs#3288

[RalfJung]

There is pretty strong justification for wanting an unwinding alloc_error_handler because it allows recovering from OOM conditions in some cases, but it also comes with a lot of potential footguns, at least similar to mutex poisoning and the like.

I think the way to deal with that is to use APIs that don't call alloc_error_handler, like Vec::try_reserve. "unwind + catch" is not an error handling strategy we usually endorse in Rust.

[maxdexh]

I could have sworn that panics in destructors were always converted to unconditional aborts, but I can't find any link in the reference that says this.

I keep mistakenly thinking the same thing, even though I have used panicking destructors for soundness holes in crates in the past. This is one of the biggest footguns in unsafe code; you need to make sure that you do not drop values of generic type unless you can deal with an unwind.

[maxdexh]

And in my PR to fix Arc::make_mut, I fell for this as well before noticing it. I think allocators are uniquely susceptible to this because they introduce owned generics into existing unsafe code when they are added to code bases.

[clarfonthey]

I think the way to deal with that is to use APIs that don't call alloc_error_handler, like Vec::try_reserve. "unwind + catch" is not an error handling strategy we usually endorse in Rust.

While I agree, I also know that catch+unwind is exactly how threads work, and this is the basis for why async runtimes like tokio also depend on this model.

I would imagine that most cases that depend on catch+unwind here are not planning to actually mitigate the error, but require a bare-minimum cleanup in the error handler, like saving some important data or logging the state during the issue. You could argue that these things are best put in the alloc error handler, but since it's hard to ensure a program is panic-free without some cursed linker shenanigans or daemonic rituals, folks might just argue for being able to catch the allocation error instead, with the caveat that any issues during unwinding still cause an abort anyway.

[maxdexh]

Some methods also don't have try_ equivalents, especially ones from traits, like clone and extend

[maxdexh]

The fact that even std, which has a pretty high review bar, is unsound under panicking allocation indicates that this is too high a bar for the entire ecosystem to uphold, and we'd be better off saying that allocation must never panic.

I thought about this a bit more and I think this is a pretty bad justification for the current requirements. Only std can rely on the methods not panicking.
The rest of the ecosystem has a higher bar than std, because implementors have to make sure not to unwind (same as std) while users of the allocator api still have to assume that unwinds are possible, as there are no guarantees.

It also means that code copied from std can become unsound outside std, which is kind of a trap for anyone that likes to use std as a guide for their own types.

[bstrie]

implementors have to make sure not to unwind (same as std) while users of the allocator api still have to assume that unwinds are possible, as there are no guarantees

I'm unclear, why would users have to assume that unwinds are possible? The guaranteed absence of unwinding is a safety invariant on Allocator itself, so users should be allowed to assume that implementors have upheld it.

[maxdexh]

It is not.

/// As an experimental requirement, implementors of the trait must guarantee that
/// none of the methods herein unwind. Due to the bound being experimental, it may be
/// removed in the future and so this cannot be relied upon by other unsafe code for
/// proving soundness.

This reads as "unwinds are possible but only std can produce them" or "unwinds are impossible but only std can take advantage of this".

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[nia-e]

per discussion on zulip, i changed the unwinding bit to a hard requirement; we may change it in the future so that an unwind out of Allocator gets auto-converted to an abort, or something of the like. either way that makes it possible to forever guarantee no unwinds come out of an allocator.

following last week's libs-api meeting, we also got the go-ahead to keep the slice return type so long as we have that extra doc comment making it clear that this shouldn't always be done.

@rustbot ready