Skip to content

Reject await in a functor body - #9220

Open
mununki wants to merge 1 commit into
masterfrom
reject-await-in-functor-bodies
Open

mununki wants to merge 1 commit into
masterfrom
reject-await-in-functor-bodies

Conversation

@mununki

@mununki mununki commented Nov 4, 2026

Copy link
Copy Markdown
Member

Fixes: #9219

await in a functor body passed the await check and compiled to await in the plain JavaScript function the functor becomes: module Make = (Source: Source) => { let value = await Source.value } compiled to function Make(Source) { let value = await Source.value; ... }, which fails to load with a SyntaxError. This happened at the top level of a file, where top-level await is allowed, and in an async function, for example for a first-class functor that an async function returns. for await and module M = await List in a functor body behaved the same, and so did module M = await List in a module nested in a plain function. #9169 made a function's body an async context exactly when the function is async; a functor is the module-level function it did not cover.

The check is in compiler/frontend/bs_builtin_ppx.ml. expr_mapper sets the async context at each Pexp_fun, but module_expr_mapper left it unchanged at a Pmod_functor, so the body took the context around the functor. module_expr_mapper now maps a functor's body with the context set to false and restores the context afterwards. The parameter's module type is not evaluated, so it keeps the outer context. structure_mapper rewrote module M = await List in a structure without checking the context, which expr_mapper checks for the same form in an expression. It now checks it under the same condition, through a check_await that both use.

  • await, for await and module M = await List in a functor body are rejected with Await on expression not in an async context, wherever the functor is: at the top level, in an async function, packed as a first-class module, with several parameters, generative, or in another functor's body. module M = await List in a module nested in a plain function is rejected with the same error.
  • Some programs that worked are now rejected. Their JavaScript was valid only because the optimizer inlined every application of the functor and dropped the functor: a functor defined and applied in an async function, a top-level functor that an interface or a signature hides, and a functor applied where it is written (module M = ((X: S) => {...})({...})). The inlining (is_a_functor in lam_pass_remove_alias.ml) is an optimization. After module G = F, G({...}) is not inlined and F stays a function with await in it. An application in a plain function inside the async function moves the await into that plain function. The changelog fragment is a fix, as for Reject await in a function that an async function returns directly #9169; reviewers may prefer breaking.
  • Also rejected: module M = await (List: {...}), which imports nothing dynamically, in a functor body or in a module in a plain function, as the same form in an expression already was. Also await in a functor under module type of, as in a module type of in a plain function. %%private around such a functor was already an error and now reports the await first.
  • Unchanged: await at the top level of a module outside functors, including in the argument of a functor application and in a parameter's module type. Also unchanged: await, for await and dynamic imports in an async function inside a functor body, and await after a functor in an async function. Functor types in signatures are not affected. Programs that still compile give the same JavaScript, and no checked-in output changes apart from the new test.

Tests: super_errors fixtures for await in a functor body at the top level, with two parameters, in another functor's body, in an async function (the inlined case) and packed in an async function; for for await and module L = await List in a functor body; and for module L = await List in a module in a plain function. Mocha tests cover await and a dynamic import in async functions in a functor body, a functor applied in an async function, await after a functor in an async function, and top-level await.

Checklist

  • Added a changelog fragment (see changes/README.md), or no release notes are needed and a maintainer should apply changelog:skip.
  • Added tests for the fix or feature.
  • Gave every commit a description below its subject, saying why it is made (see "Commit messages" in CONTRIBUTING.md).
  • Signed off every commit for the DCO (git commit -s).

Why:
    The built-in PPX checks `await` against an async context that each
    `Pexp_fun` sets to whether its function is async. A functor is a
    `Pmod_functor` module expression, which left the context as it was, so
    its body took the context around it: true at the top level of a file,
    where `await` is allowed, and in an async function. A functor compiles
    to a JavaScript function that is not async, so the output had `await`
    in a plain function. A functor body is now not an async context, and
    the context around the functor is restored after it. In a structure,
    `module M = await List` was not checked at all, so it passed in a
    functor body or a module nested in a plain function; it is now checked
    as in an expression.

Diagnostic added (await in a functor body):
Example:
    module type S = {
      let p: promise<int>
    }
    module F = (X: S) => {
      let v = await X.p
    }
Before (js): a SyntaxError when the module loads
    function F(X) {
      let v = await X.p;
      return {
        v: v
      };
    }
After (diagnostic):
    A.res:5:11-19
    Await on expression not in an async context

Diagnostic added (dynamic import in a module in a plain function):
Example:
    let f = values => {
      module M = {
        module L = await List
        let n = L.length(values)
      }
      M.n
    }
Before (js): a SyntaxError when the module loads
    function f(values) {
      let L = await import("@rescript/runtime/lib/es6/Stdlib_List.mjs");
      let n = L.length(values);
      return n;
    }
After (diagnostic):
    A.res:3:16-25
    Await on expression not in an async context

Diagnostic added (functor applied where it is defined):
Example:
    module type S = {
      let p: promise<int>
    }
    let f = async p => {
      module F = (X: S) => {
        let v = await X.p
      }
      module M = F({
        let p = p
      })
      M.v
    }
Before (js): valid, since the optimizer inlines the application
    async function f(p) {
      let v = await p;
      return v;
    }
After (diagnostic):
    A.res:6:13-21
    Await on expression not in an async context

Review: Does a working program stop compiling? Yes, where the optimizer
    inlined every application of the functor and dropped the functor: a
    functor defined and applied in an async function, as above, a
    top-level functor that an interface or a signature hides, and a
    functor applied where it is written. That depends on the optimization:
    after `module G = F`, `G({...})` is not inlined and `F` stays a
    function with `await` in it. Also rejected are `module M = await (List:
    {...})`, which imports nothing dynamically, in a functor body or a
    module in a plain function, as in an expression already, and `await`
    in a functor under `module type of`. Programs that still compile give
    the same JavaScript.

Signed-off-by: mununki <woonki.moon@gmail.com>
@github-actions

github-actions Bot commented Nov 4, 2026

Copy link
Copy Markdown

Changelog

🐛 Bug fix

  • Reject await, for await and module M = await List in a functor body, wherever the functor is defined, and module M = await List in a module nested in a function that is not async. These compiled to JavaScript with await in a function that is not async, except where the optimizer inlined every application of the functor.

Semantic Diff

1 commit · Full page

Reject await in a functor body

d8b70ba · mununki · Nov 04, 2026, 09:38 UTC

Why

The built-in PPX checks await against an async context that each Pexp_fun sets to whether its function is async. A functor is a Pmod_functor module expression, which left the context as it was, so its body took the context around it: true at the top level of a file, where await is allowed, and in an async function. A functor compiles to a JavaScript function that is not async, so the output had await in a plain function. A functor body is now not an async context, and the context around the functor is restored after it. In a structure, module M = await List was not checked at all, so it passed in a functor body or a module nested in a plain function; it is now checked as in an expression.

Diagnostic added (await in a functor body)

module type S = {
  let p: promise<int>
}
module F = (X: S) => {
  let v = await X.p
}

js · Before · a SyntaxError when the module loads

function F(X) {
  let v = await X.p;
  return {
    v: v
  };
}

diagnostic · After

A.res:5:11-19
Await on expression not in an async context

Diagnostic added (dynamic import in a module in a plain function)

let f = values => {
  module M = {
    module L = await List
    let n = L.length(values)
  }
  M.n
}

js · Before · a SyntaxError when the module loads

function f(values) {
  let L = await import("@rescript/runtime/lib/es6/Stdlib_List.mjs");
  let n = L.length(values);
  return n;
}

diagnostic · After

A.res:3:16-25
Await on expression not in an async context

Diagnostic added (functor applied where it is defined)

module type S = {
  let p: promise<int>
}
let f = async p => {
  module F = (X: S) => {
    let v = await X.p
  }
  module M = F({
    let p = p
  })
  M.v
}

js · Before · valid, since the optimizer inlines the application

async function f(p) {
  let v = await p;
  return v;
}

diagnostic · After

A.res:6:13-21
Await on expression not in an async context

Review

  • Does a working program stop compiling? Yes, where the optimizer inlined every application of the functor and dropped the functor: a functor defined and applied in an async function, as above, a top-level functor that an interface or a signature hides, and a functor applied where it is written. That depends on the optimization: after module G = F, G({...}) is not inlined and F stays a function with await in it. Also rejected are module M = await (List: {...}), which imports nothing dynamically, in a functor body or a module in a plain function, as in an expression already, and await in a functor under module type of. Programs that still compile give the same JavaScript.

@codecov

codecov Bot commented Nov 4, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.76%. Comparing base (227b697) to head (d8b70ba).

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #9220   +/-   ##
=======================================
  Coverage   81.75%   81.76%           
=======================================
  Files         457      457           
  Lines       65332    65341    +9     
=======================================
+ Hits        53413    53425   +12     
+ Misses      11919    11916    -3     
Files with missing lines Coverage Δ
compiler/frontend/bs_builtin_ppx.ml 90.61% <100.00%> (+0.28%) ⬆️

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@pkg-pr-new

pkg-pr-new Bot commented Nov 4, 2026

Copy link
Copy Markdown

Open in StackBlitz

rescript

npm i https://pkg.pr.new/rescript@9220

@rescript/belt

npm i https://pkg.pr.new/@rescript/belt@9220

@rescript/darwin-arm64

npm i https://pkg.pr.new/@rescript/darwin-arm64@9220

@rescript/linux-arm64

npm i https://pkg.pr.new/@rescript/linux-arm64@9220

@rescript/linux-x64

npm i https://pkg.pr.new/@rescript/linux-x64@9220

@rescript/runtime

npm i https://pkg.pr.new/@rescript/runtime@9220

@rescript/win32-x64

npm i https://pkg.pr.new/@rescript/win32-x64@9220

commit: d8b70ba

@github-actions

github-actions Bot commented Nov 4, 2026

Copy link
Copy Markdown

@mununki
mununki requested review from cknitt and cristianoc November 4, 2026 13:24
@mununki

mununki commented Nov 4, 2026

Copy link
Copy Markdown
Member Author

@codex review

@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Nov 4, 2026 •

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-11-04T13:26:49.086202Z d8b70ba Manual request
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@chatgpt-codex-connector

Copy link
Copy Markdown

Codex Review: Didn't find any major issues. Can't wait for the next one!

Reviewed commit: d8b70ba5c1

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

await in a functor body compiles to invalid JavaScript

2 participants