feat(traverse): add scope flags to TraverseCtx

[overlookmotel]

Add scope flags to TraverseCtx.

Closes #3189.

walk_* functions build a stack of ScopeFlags as AST is traversed, and they can be queried from within visitors with ctx.scope(), ctx.ancestor_scope() and ctx.find_scope().

The codegen which generates walk_* functions gets the info about which AST types have scopes, and how to check for strict mode from the #[visited_node] attrs on AST type definitions in oxc_ast.

A few notes:

Each scope inherits the strict mode flag from the level before it in the stack, so if you need to know "am I in strict mode context here?", ctx.scope().is_strict_mode() will tell you - no need to travel back up the stack to find out.

Scopes do not inherit any other flags from level before it. So ctx.scope() in a block nested in a function will return ScopeFlags::empty() not ScopeFlags::Function.

I had to add an extra flag ScopeFlags::Method. The reason for this is to deal with when a Function is actually a MethodDefinition, and to avoid creating 2 scopes in this case. The principle I'm trying to follow is to encode as little logic in the codegen as possible, as it's rather hidden away. Instead the codegen follows a standard logic for every node, guided by attributes which are visible next to the types in oxc_ast. This hopefully makes how Traverse's visitors are generated less mysterious, and easier to change.

The case of Function within MethodDefinition is a weird one and would not be possible to implement without encoding a magic "special case" within the codegen without this extra ScopeFlags::Method variant. Its existence does not alter the operation of any other code in Oxc which uses ScopeFlags.

In my view ScopeFlags might benefit from a little bit of an overhaul anyway. I believe we could pack more information into the bits and make it more useful.

[overlookmotel]

• feat(traverse): add scope flags to TraverseCtx #3229 👈
• refactor(ast): order AST type fields in visitation order #3228
• refactor(ast): add is_strict methods #3227
• refactor(traverse): do not expose TraverseCtx::new #3226
• main

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

Join @overlookmotel and the rest of your teammates on Graphite

[codspeed-hq]

CodSpeed Performance Report

Merging #3229 will not alter performance

_{Comparing 05-10-feat_traverse_add_scope_flags_to_traversectx_ (46c02ae) with main (132db7d)}

Summary

✅ 27 untouched benchmarks

[Boshen]

I may have missed this, where is the logic for checking "use strict" inside a function?

Edit: oh it's in another PR.

[Boshen]

Merge activity

• May 11, 12:16 AM EDT: @Boshen started a stack merge that includes this pull request via Graphite.
• May 11, 12:19 AM EDT: Graphite couldn't merge this pull request because a downstack PR refactor(ast): add is_strict methods #3227 failed to merge.
• May 11, 12:38 AM EDT: Boshen added this pull request to the Graphite merge queue.
• May 11, 12:46 AM EDT: Boshen merged this pull request with the Graphite merge queue.

[overlookmotel]

@Boshen FYI The logic for checking for "use strict" is in the #[visited_node] attr on Function (strict_if clause):

oxc/crates/oxc_ast/src/ast/js.rs

Lines 2134 to 2143 in ec41dba

	#[visited_node(
	scope(ScopeFlags::Function),
	// Don't create a 2nd scope if `MethodDefinition` already created one
	scope_if((ctx.scope() & ScopeFlags::Modifiers).is_empty()),
	strict_if(self.body.as_ref().is_some_and(|body| body.has_use_strict_directive()))
	)]
	#[derive(Debug, Hash)]
	#[cfg_attr(feature = "serialize", derive(Serialize, Tsify))]
	#[cfg_attr(feature = "serialize", serde(rename_all = "camelCase"))]
	pub struct Function<'a> {

The additional is_use_strict and has_use_strict_directive methods added in PR further down the stack were just to make the code in #[visited_node] less verbose.