fix(ast_codegen, ast): visit ExpressionArrayElement as Expression.

[rzvxa]

hotfix for #4060

I just added an edge case, We can come back to it later on and make it a standard in our codegen.

The diff is big because it causes the code to reorder, The edge case generated code doesn't follow the order in which they are defined in the source of truth(eg js.rs)

[graphite-app]

Your org has enabled the Graphite merge queue for merging into main

Add the label “merge” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. Or use the label “hotfix” to add to the merge queue as a hot fix.

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

[rzvxa]

• fix(ast_codegen, ast): visit ExpressionArrayElement as Expression. #4061 👈
• main

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

Join @rzvxa and the rest of your teammates on Graphite

[Dunqing]

Not just Expression, we need to visit the corresponding AST for all @inherit XXX

[codspeed-hq]

CodSpeed Performance Report

Merging #4061 will improve performances by 6.49%

_{Comparing 07-05-fix_ast_codegen_ast_visit_expressionarrayelement_as_expression_ (cb78ece) with 07-05-fix_ast_codegen_ast_visit_expressionarrayelement_as_expression_ (ec5bfd0)}

Summary

⚡ 2 improvements
✅ 26 untouched benchmarks

Benchmarks breakdown

	Benchmark	07-05-fix_ast_codegen_ast_visit_expressionarrayelement_as_expression_	07-05-fix_ast_codegen_ast_visit_expressionarrayelement_as_expression_	Change
⚡	prepass[react.development.js]	218.3 µs	207.1 µs	+5.45%
⚡	prepass[typescript.js]	29.1 ms	27.3 ms	+6.49%

[rzvxa]

Not just Expression, we need to visit the corresponding AST for all @inherit XXX

We already do this for the inherited enums, ExpressionArrayElement is special because it doesn't exist, I use the visit_as attribute to visit an arbitrary Expression as a non-existing type ExpressionArrayElement, That's actually what causes this bug, Since I was generating a new walk for this based on the Expression supertype.

It also happens in FinallyClause and ClassHeritage but those 2 are structures so It doesn't need to consider inheritance.
For now, I used an edge case, But we should standardize the behavior or visit_as on enums to act this way out of the gate.

---

Edit:

Here is an example:

oxc/crates/oxc_ast/src/generated/visit.rs

Lines 2887 to 2895 in ec5bfd0

	pub fn walk_argument<'a, V: Visit<'a>>(visitor: &mut V, it: &Argument<'a>) {
	let kind = AstKind::Argument(visitor.alloc(it));
	visitor.enter_node(kind);
	match it {
	Argument::SpreadElement(it) => visitor.visit_spread_element(it),
	match_expression!(Argument) => visitor.visit_expression(it.to_expression()),
	}
	visitor.leave_node(kind);
	}

[Dunqing]

Thanks for the explanation, I see the root cause

[rzvxa]

Thanks for the explanation, I see the root cause

Your question actually showed me another edge case, ClassHeritage is also an alias for Expression I have to add that one to our edge case too.

[Boshen]

Confirmed in Rolldown by testing locally.