feat(allocator): replace allocator_ap2's Vec with Vec2

[Dunqing]

Just replace allocator_ap2's Vec with Vec2, and make some changes to make it compile successfully.

[Dunqing]

• refactor(allocator/vec2): rename parameters and method name to align with std #9858 : 2 dependent PRs (#9855 , #9857 )
• feat(allocator/vec2): align the retain method with the standard implementation #9752
• feat(allocator/vec): remove ManuallyDrop wrapper #9742
• feat(allocator): remove drop operations from Vec2 #9679
• feat(allocator): replace allocator_ap2's Vec with Vec2 #9656 👈 (View in Graphite)
• feat(allocator): add Vec2::retain_mut method #9655
• feat(allocator): connect Vec2 module and make it compile #9647
• refactor(allocator/vec): disable lint warnings in vec2 files #9730
• docs(allocator/vec): fix link in doc comment for Vec2 #9729
• refactor(allocator/vec): comment out feature-gated methods #9728
• 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.

[codspeed-hq]

CodSpeed Performance Report

Merging #9656 will improve performances by 5.27%

_{Comparing 03-11-feat_allocator_replace_allocator_ap2_s_vec_with_vec2 (5cc614a) with main (faca7a8)}

Summary

⚡ 3 improvements
✅ 30 untouched benchmarks

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
⚡	transformer[antd.js]	53.9 ms	51.8 ms	+3.94%
⚡	transformer[checker.ts]	24.4 ms	23.2 ms	+5.27%
⚡	transformer[pdf.mjs]	10.7 ms	10.3 ms	+4.05%

[overlookmotel]

Here's a minimal reproduction of the lifetimes problem:

use bumpalo::{Bump, collections::Vec};

struct Test<'b> {
    _dummy: &'b (),
}

impl<'b> Test<'b> {
    pub fn test_vec(input: &Vec<'b, u64>, bump: &'b Bump) -> u64 {
        let vec = Vec::from_iter_in(input.iter(), bump);
        //                          ^^^^^^^^^^^^
        // Error: explicit lifetime required in the type of `input`. lifetime `'b` required.

        Self::sum(&vec)
    }

    fn sum(vec: &Vec<'b, &u64>) -> u64 {
        vec.iter().copied().sum()
    }
}

This fixes it:

- fn sum(vec: &Vec<'b, &u64>) -> u64 {
+ fn sum(vec: &Vec<'_, &u64>) -> u64 {

But I don't think that should be necessary. I think it should compile fine as is.

Some discussion (but no complete conclusion) here: fitzgen/bumpalo#171

[Dunqing]

After #9733, the changes to oxc_isolated_declarations should no longer be required (I hope!)

Yes! You are right!

[Dunqing]

Here's a minimal reproduction of the lifetimes problem:

use bumpalo::{Bump, collections::Vec};

struct Test<'b> {
    _dummy: &'b (),
}

impl<'b> Test<'b> {
    pub fn test_vec(input: &Vec<'b, u64>, bump: &'b Bump) -> u64 {
        let vec = Vec::from_iter_in(input.iter(), bump);
        //                          ^^^^^^^^^^^^
        // Error: explicit lifetime required in the type of `input`. lifetime `'b` required.
        Self::sum(&vec)
    }

    fn sum(vec: &Vec<'b, &u64>) -> u64 {
        vec.iter().copied().sum()
    }
}

This fixes it:

- fn sum(vec: &Vec<'b, &u64>) -> u64 {
+ fn sum(vec: &Vec<'_, &u64>) -> u64 {

But I don't think that should be necessary. I think it should compile fine as is.

Some discussion (but no complete conclusion) here: fitzgen/bumpalo#171

Does that mean we should align the implementation with std does? Accepting allocator rather than a bump lifetime?

[overlookmotel]

I remain unsure whether the T: 'bump lifetime bound is required on vec2::Vec (and on its various impls).

But now the only place this impacts our code is requiring a C: 'new_alloc bound on CloneIn for Vec, which is unproblematic.

So I think we can merge this now, and resolve the lifetime question later on.

[overlookmotel]

Merge activity

• Mar 14, 1:47 AM EDT: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Mar 14, 2:12 AM EDT: A user added this pull request to the Graphite merge queue.
• Mar 14, 2:21 AM EDT: A user merged this pull request with the Graphite merge queue.

[overlookmotel]

Note that as well as the positive perf impact on transformer, this PR also has a small negative effect on parser benchmarks.

I imagine this may be for same reason as saw that same performance effect in #9301.

We can take a look at parser code and see if we can improve that by reserving initial capacity in Vecs where we know they're not going to remain empty.

[Dunqing]

We can take a look at parser code and see if we can improve that by reserving initial capacity in Vecs where we know they're not going to remain empty.

Let me take a look at this

[overlookmotel]

Let me take a look at this

We may want to look at implementing the optimization in #9301 first. (or that may not even be an optimization any more!)