feat(allocator/vec2): align the retain method with the standard implementation

[Dunqing]

The documentation and the implementation are copied from https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#2095-209.

After this change, drain_filter is no longer needed, so remove it.

[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 👈 (View in Graphite)
• 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
• 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 Instrumentation Performance Report

Merging #9752 will not alter performance

_{Comparing 03-13-feat_allocator_vec2_align_the_retain_method_with_the_standard_implementation (6a8c2fd) with main (07f2a25)}

Summary

✅ 33 untouched benchmarks

[overlookmotel]

Do we want to remove drain_filter? It looks quite useful. e.g.:

// Move all statements except `import`s and `export`s into a nested `BlockStatement`
let stmts_to_move = program.body.drain_filter(|stmt| stmt.is_module_declaration());
let stmts_to_move = Vec::from_iter_in(stmts_to_move, ast.allocator);
program.body.push(ast.statement_block(SPAN, stmts_to_move));

This could make e.g. using transform more efficient:

oxc/crates/oxc_transformer/src/proposals/explicit_resource_management.rs

Lines 218 to 232 in d13817e

	let program_body = ctx.ast.move_vec(&mut program.body);
	let (mut program_body, inner_block): (
	ArenaVec<'a, Statement<'a>>,
	ArenaVec<'a, Statement<'a>>,
	) = program_body.into_iter().fold(
	(ctx.ast.vec(), ctx.ast.vec()),
	|(mut program_body, mut inner_block), mut stmt| {
	let address = stmt.address();
	match stmt {
	Statement::FunctionDeclaration(_)
	| Statement::ImportDeclaration(_)
	| Statement::ExportAllDeclaration(_) => {
	program_body.push(stmt);
	}

But if you want to remove it now, and we add it (or something like it) back again later, I'm fine with that.

[Dunqing]

Do we want to remove drain_filter? It looks quite useful. e.g.:

// Move all statements except `import`s and `export`s into a nested `BlockStatement`
let stmts_to_move = program.body.drain_filter(|stmt| stmt.is_module_declaration());
let stmts_to_move = Vec::from_iter_in(stmts_to_move, ast.allocator);
program.body.push(ast.statement_block(SPAN, stmts_to_move));

This could make e.g. using transform more efficient:

oxc/crates/oxc_transformer/src/proposals/explicit_resource_management.rs

Lines 218 to 232 in d13817e

	let program_body = ctx.ast.move_vec(&mut program.body);
	let (mut program_body, inner_block): (
	ArenaVec<'a, Statement<'a>>,
	ArenaVec<'a, Statement<'a>>,
	) = program_body.into_iter().fold(
	(ctx.ast.vec(), ctx.ast.vec()),
	|(mut program_body, mut inner_block), mut stmt| {
	let address = stmt.address();
	match stmt {
	Statement::FunctionDeclaration(_)
	| Statement::ImportDeclaration(_)
	| Statement::ExportAllDeclaration(_) => {
	program_body.push(stmt);
	}

But if you want to remove it now, and we add it (or something like it) back again later, I'm fine with that.

Thank you for bringing this example up. I've checked the std library doesn't include this method, and doesn't remember where a case in our codebase can use this method, so I think it can be removed. Now considering there is a case that can benefit from this method, I will keep it.

[overlookmotel]

Merge activity

• Mar 25, 10:05 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 25, 10:05 AM EDT: A user added this pull request to the Graphite merge queue.
• Mar 25, 2:08 PM UTC: The Graphite merge queue couldn't merge this PR because it was not satisfying all requirements (Failed CI: 'Test (ubuntu-latest)', 'Test (macos-latest)').
• Mar 25, 10:19 AM EDT: The merge label '0-merge' was removed. This PR will no longer be merged by the Graphite merge queue
• Mar 25, 10:20 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 25, 10:28 AM EDT: A user added this pull request to the Graphite merge queue.
• Mar 25, 10:28 AM EDT: A user merged this pull request with the Graphite merge queue.