rustc_arena: handle recursive allocation, don't trust size_hint

[tgnottingham]

In DroplessArena::alloc_from_iter, handle allocating from iterators
whose next calls may themselves allocate on the arena. Also, do not
trust the iterator's size_hint implementation for correctness.
These changes were already made for TypedArena in #67003.

[rust-highfive]

r? @davidtwco

(rust_highfive has picked a reviewer for you, use r? to override)

[tgnottingham]

r? @Mark-Simulacrum

[tgnottingham]

I attempted to implement a performance mitigation to avoid the extra copying in certain cases, but it didn't work out.

If an exact size hint was available, the mitigation would copy into an appropriately-sized TypedArenaChunk instead of a SmallVec. To avoid wasting space, it would still copy the data from that chunk into the existing last chunk if it could fit. But if it couldn't fit in the last chunk, it would just append the chunk as an optimization.

It managed to worsen performance, probably due to a combination of complexity, that it doesn't avoid allocating sometimes like the SmallVec approach does, and that the optimization doesn't kick in all that often because it tries to avoid wasting space. I probably could have explored a SmallVec-like optimization that avoided allocating, but it seems like the potential gains are marginal.

[est31]

Is this PR a good idea?

First, next allocating doesn't cause any issues for the dropless arena. We do self.alloc_raw before we call the next function in any way.

Regarding the second point, if size_hint's minimum matches the maximum, then it's required to be accurate, otherwise it's a bug in the iterator. This may not cause unsound code, but from what I can tell it doesn't. If the size hint is too low, then write_from_iter aborts early. If it's too high, we have some unused memory left, but that's no problem because the arena is dropless, so we never run any destructor on that unused memory.

cc @bugadani

[tgnottingham]

Ah, okay. I see I missed the critical difference as to why this was safe for DroplessArena.

With DroplessArena, we can update self.ptr, etc. before iterating, which means that any allocation resulting from a call to next() won't write to the memory reserved for our current iterator. But we can't do this for TypedArena, because if we update self.ptr, etc. prematurely, then if next() panics, we would end up dropping the wrong number of elements.

Nevermind then. :)

[est31]

With DroplessArena, we can update self.ptr, etc. before iterating, which means that any allocation resulting from a call to next() won't write to the memory reserved for our current iterator. But we can't do this for TypedArena, because if we update self.ptr, etc. prematurely, then if next() panics, we would end up dropping the wrong number of elements.

Yup, that's the logic!