refactor(ast)!: Remove AstKind for Argument

[taearls]

Part of #11490

had to open this new PR because #12525 was closed by mistake.

Motivation

AstKind::Argument was an architectural inconsistency. The AstKind system is designed for struct types, but Argument is an enum (SpreadElement | Expression). This created unnecessary complexity in the AST traversal system.

Solution

Replace AST-based argument detection with span-based utilities. Instead of traversing the tree to find AstKind::Argument nodes, we now use direct span containment checks.

New Utilities

Added to oxc_linter/src/ast_util.rs:

pub fn is_node_exact_call_argument<'a>(
    node: &AstNode<'a>,
    ctx: &LintContext<'a>
) -> bool

Checks if a node is exactly a direct argument to its parent call expression by checking if the parent is a call and the node's span matches one of the argument spans.

pub fn is_node_within_call_argument<'a>(
    node: &AstNode<'a>,
    call: &CallExpression<'a>,
    target_arg_index: usize,
) -> bool

Checks if a node is nested within a specific argument at the given index of the provided call expression.

Added to oxc_ast/src/ast_kind_impl.rs:

pub fn has_argument_with_span(&self, span: Span) -> bool

Checks if this AstKind is a call expression with an argument matching the given span.

pub fn is_callee_with_span(&self, span: Span) -> bool

Checks if this AstKind is a call expression whose callee matches the given span.

Architecture Change

Before:

// Required parent traversal and state management
match parent.kind() {
    AstKind::Argument { .. } => {
        // Check grandparent for call context
    }
}

After:

// Direct span-based detection
if is_node_exact_call_argument(node, ctx) {
    // Node is a direct call argument
}

if is_node_within_call_argument(node, call, 0) {
    // Node is within first argument
}

Impact

• AST: Removed AstKind::Argument variant, reduced AST_TYPE_MAX from 186 → 185
• Linter: Updated 38 rules across React, Promise, ESLint, Unicorn, Jest, and other plugins
• Formatter: Modified parenthesization behavior for expressions in call arguments. The removal of AstKind::Argument caused the formatter to make different formatting decisions for arrow functions and object expressions used as arguments, generally producing more compact output (fewer parentheses). Snapshot tests show formatting changes while maintaining Prettier conformance pass rates.
• Performance: Span comparisons are O(1) operations, eliminating the need for parent AST traversal in many cases

Testing

• ✅ All linter tests pass with updated rules
• ✅ Prettier conformance suites maintain the same passing percentage
• ⚠️ Note: Formatter snapshot tests show output changes for some patterns (arrow functions as arguments now formatted more compactly)

Breaking Changes

None - this is an internal refactoring that doesn't affect public APIs.

[codspeed-hq]

CodSpeed Performance Report

Merging #13902 will improve performances by 5.8%

_{Comparing taearls:07-08-refactor_ast_remove_astkind_for_argument_ (be22770) with main (2bbee24)¹}

Summary

⚡ 2 improvements
✅ 35 untouched

Benchmarks breakdown

	Mode	Benchmark	BASE	HEAD	Change
⚡	Simulation	linter[binder.ts]	49.2 ms	46.5 ms	+5.8%
⚡	Simulation	linter[react.development.js]	19.3 ms	18.7 ms	+3.47%

Footnotes

1. No successful run was found on main (d5fa3f8) during the generation of this report, so 2bbee24 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[taearls]

the CI is fully passing now! I still need to take some time to review my own changes, but I think generally this is ready for review now

[overlookmotel]

@taearls Sorry this has taken so long to get to, and thanks for constantly keeping the PR updated. We're aiming to (finally) get this merged next week. @camc314 and @Dunqing are reviewing the parts related to linter and formatter respectively, and then I'm going to do a 2nd pass through the whole thing. I'll co-ordinate with them both on Monday.

[taearls]

@taearls Sorry this has taken so long to get to, and thanks for constantly keeping the PR updated. We're aiming to (finally) get this merged next week. @camc314 and @Dunqing are reviewing the parts related to linter and formatter respectively, and then I'm going to do a 2nd pass through the whole thing. I'll co-ordinate with them both on Monday.

hey! I appreciate that a lot. It's all good! I know this is a big change so I can understand that it's harder to prioritize this with everything else that's in flight right now, especially with the formatter.

I just rebased onto main earlier today and got the conformance tests to the same baseline as was on main (with some minor improvements!) so it's all ready to go.

[overlookmotel]

Amazing. Thank you.

Can I please ask one thing? Could you please rebase onto main (rebase not merge) and squash everything down to a single commit? The list of commits on this page is so long that it's quite hard to find the review comments!

[taearls]

Amazing. Thank you.

Can I please ask one thing? Could you please rebase onto main (rebase not merge) and squash everything down to a single commit? The list of commits on this page is so long that it's quite hard to find the review comments!

done!

[camc314]

@taearls Thank you for your work on this!

[overlookmotel]

Yes, thank you thank you thank you @taearls. I've actually not reviewed yet, but we decided best to just get it merged now before it accrues more merge conflicts, and I'll go through it later this week, and I can make any follow-ups then.

[taearls]

Yes, thank you thank you thank you @taearls. I've actually not reviewed yet, but we decided best to just get it merged now before it accrues more merge conflicts, and I'll go through it later this week, and I can make any follow-ups then.

That makes sense. I'm happy to help! This effort taught me a lot about working with this project, and I feel much more comfortable in it as a whole because of it.

Let me know if I can be helpful with any follow-up items.