must visit decorators before enter_node and enter_scope if have decorators field

[Dunqing]

Please see:

oxc/crates/oxc_semantic/src/builder.rs

Lines 1502 to 1506 in daea29c

	fn visit_class(&mut self, class: &Class<'a>) {
	// Class level decorators are transpiled as functions outside of the class taking the class
	// itself as argument. They should be visited before class is entered. E.g., they inherit
	// strict mode from the enclosing scope rather than from class.
	for decorator in &class.decorators {

[Dunqing]

@rzvxa cc

[rzvxa]

We already have the #[scope(enter_before)] mechanism used on Class If you look at the source of truth you'd see it is defined like this:

/// Class Definitions
#[visited_node]
#[scope(flags(ScopeFlags::StrictMode))]
#[derive(Debug)]
#[cfg_attr(feature = "serialize", derive(Serialize, Tsify))]
#[cfg_attr(feature = "serialize", serde(rename_all = "camelCase"))]
pub struct Class<'a> {
    pub r#type: ClassType,
    #[cfg_attr(feature = "serialize", serde(flatten))]
    pub span: Span,
    pub decorators: Vec<'a, Decorator<'a>>,
    #[scope(enter_before)]
    pub id: Option<BindingIdentifier<'a>>,
    // ...
}

Which generates this:

    pub fn walk_class<'a, V: Visit<'a>>(visitor: &mut V, it: &Class<'a>) {
        let kind = AstKind::Class(visitor.alloc(it));
        visitor.enter_node(kind);
        visitor.visit_decorators(&it.decorators);
        visitor.enter_scope(ScopeFlags::StrictMode);
        if let Some(id) = &it.id {
            visitor.visit_binding_identifier(id);
        }
        // ...
        visitor.leave_node(kind);
        visitor.leave_scope();
    }

I'll add the support for a similar mechanism to mark the enter_node.

[overlookmotel]

I understand why enter_scope should be after visiting decorators, but why also enter_node?

[Dunqing]

I understand why enter_scope should be after visiting decorators, but why also enter_node?

You are right. There is an incorrect behavior here. See #4156 (comment)

We shouldn't visit decorators before enter_node. That will cause we don't know the decorators from where in visit_decoratots. And may make it hard to implement the decorators plugin of the transformer (I guess)