We should also enter a new production parameter scope with [Await] parameter when topLevelAwait is enabled, e.g.

module { await 42 }

See

189bc49 👍

I personally prefer moduleBlocks for brevity.

5dd532b 👍

I think we should wrap the module blocks within a BlockStatement. Like we did for DoExpression: https://github.com/babel/babel/blob/main/packages/babel-parser/ast/spec.md#doexpression

The BlockStatement is of Scopeable alias, and many more. So when traversing the module body statements in a module block, path.scope can be well defined, currently it points to the scope when the ModuleExpression defines since it is not Scopeable.

We could also consider Program instead of BlockStatement.

Program allows to include Directive in its body. But Module Blocks doesn't seem to allow that. Also current BlockStatement body cannot have ModuleDeclaration.

Should we add new node type? or extends BlockStatement?

I would be really surprised if module blocks don't allow directives, since they are currently also allowed in blocks and functions.

Oh sorry, I misunderstood about directives in ECMAScript spec. Module blocks allows directives. As you said, we can use Program.

Btw, the original reason I proposed Program is that in many transforms we need to inject things to the top-level.
We find the top-level with path.findParent(p => p.isProgram()), and this would nicely work out of the box with module blocks.

Fixed at e381be0

Can you a test case about the locality of this.inModule? We should throw for

// sourceType: "script"
module { await: 1 }

because "await" as a label identifier is forbidden when the goal syntax is Module: https://tc39.es/ecma262/#sec-identifiers-static-semantics-early-errors

b4adac3 👍

We should also construct new classScope like we did in

otherwise it will mess up with upper class definition:

class B {
  #p() {
    module {
      class C { [this.#p]; } // it should not have access to `#p` defined across the module block
    }
  }
}

I wonder if it would be better to introduce a new initializeScopes function, so htat if we have to initialize more things we only have to update one place.

Maybe something like

const oldScopes = this.initializeScopes();
node.body = this.parseProgram(program, tt.braceR, "module"));
Object.assign(this, oldScopes);

and then we re-use initializeScopes in Parser's constructor.

Nit: no need to comment this. It was only needed for class fields because Flow didn't support the declare keyword.

If remove this comment, ESLint warns:

error: 'SourceType' is defined but never used (no-unused-vars) at packages/babel-parser/src/parser/expression.js:58:15:
56 | } from "../util/expression-scope";
57 | import { Errors } from "./error";
> 58 | import type { SourceType } from "../options";
   |               ^
59 | 
60 | export default class ExpressionParser extends LValParser {
61 |   // Forward-declaration: defined in statement.js

Sorry I'm not familiar with Flow, what should we do?

It's ok like this then.

We can use this.lookaheadCharCode() === charCodes.rightCurlyBrace and avoid the expensive this.lokahead().

Also we can avoid lookahead via using new hasFollowingLineBreak, thank you. 370953a

I wonder if it would be better to introduce a new initializeScopes function, so htat if we have to initialize more things we only have to update one place.

Maybe something like

const oldScopes = this.initializeScopes();
node.body = this.parseProgram(program, tt.braceR, "module"));
Object.assign(this, oldScopes);

and then we re-use initializeScopes in Parser's constructor.

Can currentScope.flags & SCOPE_PROGRAM ever be false?

I seem to have made a mistake when I added this... 15c8306

Another test:

let foo;
module {
  export { foo };
}