fix(allocator/vec2): guard against cap rather than allocation size exceeding u32::MAX

[Dunqing]

• resolves: feat(allocator/vec2): change len and cap fields from usize to u32 #10884 (comment)

Introduce a cap_guard to guard against cap exceeding u32::MAX and revert alloc_guard to before.

[Dunqing]

• fix(allocator/vec2): guard against cap rather than allocation size exceeding u32::MAX #11064 👈 (View in Graphite)
• main

---

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• 0-merge - adds this PR to the back of the merge queue
• hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[Copilot]

Pull Request Overview

This pull request fixes the capacity guard logic in the vector allocator to check the capacity rather than the allocation size against u32::MAX. It replaces the old alloc_guard with the new cap_guard function, updates related calls in growth functions, and revises the associated comments.

• Replace alloc_guard with cap_guard in critical allocation and growth functions.
• Update inline documentation to accurately describe the guard behavior.
• Adjust error handling to use unwrap_err_unchecked in from_raw_parts_in.

[codspeed-hq]

CodSpeed Instrumentation Performance Report

Merging #11064 will not alter performance

_{Comparing 05-16-fix_allocator_vec2_guard_against_cap_rather_than_allocation_size_exceeding_u32_max (97ba73b) with main (5dcd0f1)}

Summary

✅ 36 untouched benchmarks

[Dunqing]

A little performance regression

[Dunqing]

Kinda relate to this PR because too many checks in grow_* methods, as you just mentioned in the meeting, so I want to bring it up here.

Rust uses Layout::repeat rather than Layout::array<T> in grow_exact and grow_amortized, which has fewer checks. Before I want to align this part as well, but unfortunately, the Layout::repeat is unstable, but it is quite easy to copy to our own.

https://github.com/rust-lang/rust/blob/c79bbfab78dcb0a72aa3b2bc35c00334b58bfe2e/library/alloc/src/raw_vec/mod.rs#L819C1-L822C2

/cc @overlookmotel Maybe we can take this way to reduce some checks, what do you think?

[overlookmotel]

We have 3 checks:

• (len as usize).checked_add(additional)
• cap_guard / alloc_guard
• Layout::array

We should ideally try to remove at least 1 of these checks, and possibly remove 2.

---

We should be able to combine the last 2 checks, and create Layout without checks (Layout::from_size_align_unchecked).

impl<'a, T> RawVec<'a, T> {
    const MAX_CAP: usize = {
        let max_cap_elements = u32::MAX as usize;
        let max_cap_due_to_size = (isize::MAX as usize) / size_of::<T>();
        min(max_cap_elements, max_cap_due_to_size)
    };
}

const fn min(a: usize, b: usize) -> usize {
    if a < b { a } else { b }
}

Check if requested capacity is greater than Self::MAX_CAP, and return an error if it is.

We've now satisfied the conditions of Layout::from_size_align_unchecked, so can skip the 3rd check.

(I think this covers both 32-bit and 64-bit systems)

---

As to how to remove the checked_add too, we already have an example in RawVec we could adapt. Note that this does not use checked arithmetic because overflow is impossible:

oxc/crates/oxc_allocator/src/vec2/raw_vec.rs

Lines 622 to 627 in c29b1b8

	fn needs_to_grow(&self, len: u32, additional: usize) -> bool {
	// `self.cap().wrapping_sub(len) as usize` is safe because
	// `self.cap()` is `u32` and `len` is `u32`, so the result
	// is guaranteed to be less than `usize::MAX`.
	additional > self.cap().wrapping_sub(len) as usize
	}

This last one may or may not be a perf gain. We remove one branch but the arithmetic takes more operations.

[Dunqing]

@overlookmotel Thank you for reviewing this. I intend to work on it when you finish your work on Vec so that we don't conflict, or if you want, feel free to take it over.

[overlookmotel]

I'm pretty much done with follow-up PRs about Vec now. The stack up to #11081 is ready to review and merge, if you're OK with the changes. The last 2 PRs in that stack I'm less sure about - they were experiments really, but they shouldn't block other work on Vec.

Concerning this PR: I'd be happy to leave it to you, if that's OK.

[overlookmotel]

Ah I see you've already reviewed most of that stack. I'll merge them now. Please review the last one #11081 when you get a chance.