Add @res.hoistedFunction support for flat JS export - #8402
Conversation
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6dfddc0098
ℹ️ 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".
rescript
@rescript/belt
@rescript/darwin-arm64
@rescript/darwin-x64
@rescript/linux-arm64
@rescript/linux-x64
@rescript/runtime
@rescript/win32-x64
commit: |
b0e30dd to
da4b5b3
Compare
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: da4b5b3307
ℹ️ 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".
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #8402 +/- ##
==========================================
+ Coverage 75.95% 75.98% +0.02%
==========================================
Files 474 474
Lines 62905 63054 +149
==========================================
+ Hits 47779 47909 +130
- Misses 15126 15145 +19
🚀 New features to boost your workflow:
|
|
Developer playground preview: https://rescript-lang.github.io/rescript/dev-playground/?version=pr-8402 |
da4b5b3 to
8595ead
Compare
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8595ead79d
ℹ️ 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".
Signed-off-by: Christoph Knittel <ck@cca.io>
8595ead to
3c50e90
Compare
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3c50e90bf7
ℹ️ 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".
Signed-off-by: Christoph Knittel <ck@cca.io>
Signed-off-by: Christoph Knittel <ck@cca.io>
46cebb7 to
ea70870
Compare
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ea708706b9
ℹ️ 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".
Signed-off-by: Christoph Knittel <ck@cca.io>
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: cb7e60c88e
ℹ️ 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".
Signed-off-by: Christoph Knittel <ck@cca.io>
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 24763f159e
ℹ️ 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".
Signed-off-by: Christoph Knittel <ck@cca.io>
Signed-off-by: Christoph Knittel <ck@cca.io>
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f52fd1a63e
ℹ️ 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".
Signed-off-by: Christoph Knittel <ck@cca.io>
Signed-off-by: Christoph Knittel <ck@cca.io>
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b8b8c209d7
ℹ️ 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".
Signed-off-by: Christoph Knittel <ck@cca.io>
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3f6fae317d
ℹ️ 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".
Signed-off-by: Christoph Knittel <ck@cca.io>
|
@codex review |
|
Codex Review: Didn't find any major issues. Can't wait for the next one! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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". |
Signed-off-by: Christoph Knittel <ck@cca.io>
cristianoc
left a comment
cristianoc
left a comment
There was a problem hiding this comment.
I wonder whether we should frame this problem more broadly as an opt-in module export ABI. A module could designate one function as its JavaScript representation, so that a ReScript access such as M.make is emitted as a direct reference to an exported function named M. This would give component-like modules a natural, stable JavaScript identity without exposing the implementation detail that their principal function happens to be called make.
For example:
module Button = {
@module.owner
let make = (~label) => React.string(label)
}could be represented as:
function Button(props) {
// ...
}
export { Button };A consumer would still write:
Button.make(~label="Save")but the generated JavaScript would call:
Button({label: "Save"})The same idea would apply across files and nested modules. Given:
// Sidebar.res
module Provider = {
@module.owner
let make = (~children) => children
}this source expression:
Sidebar.Provider.make(~children)could compile to a direct reference to the Provider export:
import * as Sidebar from "./Sidebar.res.mjs";
Sidebar.Provider({children});For deeper nesting, an implementation could flatten the module path while omitting the designated member name:
Layout.Sidebar.Provider.makeLayout.Sidebar$Provider(props)Compared with adding an export such as Provider$make while retaining Provider.make, this model defines one preferred JavaScript identity rather than two parallel identities. It would be an explicit, opt-in change to the module's generated JavaScript API, so the compatibility implications would also be clear.
There are, of course, many details to work out before this could become a complete design. A module may contain values other than its designated function:
module Button = {
@module.owner
let make = props => ...
let defaultSize = 20
let renderIcon = icon => ...
}One possible representation would be:
export function Button(props) {
// ...
}
export const Button$defaultSize = 20;
export function Button$renderIcon(icon) {
// ...
}but that is only one option. We would also need to decide how whole-module uses, module aliases, include, functors, first-class and recursive modules, signatures, naming collisions, separate compilation, and existing JavaScript consumers should behave. I do not think we need to settle all of those questions in this PR, but before committing to the more general hoisted-function machinery, it seems worth deciding whether this opt-in module ABI is the direction we ultimately want—especially for React components and other modules organized around one principal function.
|
This is an interesting direction, but I think it describes a substantially broader module ABI feature rather than a simplification of this PR. A few thoughts:
For this PR, I would therefore prefer to keep the additive behavior: preserve the normal module representation and provide an additional direct export. An opt-in owner ABI could be explored separately and could likely reuse much of the path and export machinery introduced here. |
| in | ||
| let args_code : J.block = List.concat args_block in | ||
| let exp = | ||
| (* TODO: all can be done in [compile_primitive] *) |
There was a problem hiding this comment.
forgotten or is that one for me to continue?
There was a problem hiding this comment.
This part of the code was just moved, the TODO was there before.
3 participants
Summary
Adds
@res.hoistedFunction, a compiler-supported attribute for exporting nested module functions through flat JS exports.A function defined inside an exported module can now be marked as hoisted. The compiler keeps the normal nested module shape, but also emits a root-level alias/export for the function and records that alias in
.cmjmetadata so downstream modules can import it directly.Motivation
Nested module functions are normally emitted and consumed through property access:
This is the first step for my take on #8293. That work needs generated JSX code for React Server Components to expose nested component functions through stable flat JS exports:
Because producers and consumers are compiled separately, the consumer cannot infer from the source path alone whether
Producer.A.B.makealso has a flat export. The producer therefore records hoisted paths in.cmjmetadata, and consumers use that metadata to emit the flat import when it is available.Design
Source Marker
The feature introduces:
The attribute applies only to function bindings. Attributes on unsupported syntax locations, including external declarations, are reported by the compiler's standard unused-attribute check. Attributes on value bindings that cannot be hoisted for semantic reasons—such as non-function values or unsupported binding patterns—produce a misplaced-attribute warning.
The attribute deliberately applies only to nested module function bindings with a fixed exported path, matching the intended use case. Local functions, functions declared directly at the file root, local modules, and functor bodies cannot form such an export and produce a misplaced-attribute warning. The complete path must also remain visible after signature coercion: if an explicit module signature or the file's
.resihides the function or an enclosing module, the compiler reports the same warning and does not generate an alias.Producer Output
When an exported module contains a hoisted nested function, the compiler keeps the original module structure and adds a root-level alias.
For a source path like:
the compiler emits a flat export:
The nested function remains available at its normal path, while the flat alias is exported as a separate JS value.
Path Identity and Exotic Identifiers
The flat JavaScript name cannot safely identify the original source path by itself.
Representing a nested path by joining its segments with
$would be ambiguous because ReScript allows escaped identifiers containing$. For example, these are distinct source paths:However, both have the same natural flat JavaScript spelling:
Encoding the path segments in the generated export name would remove the ambiguity, but it would also produce surprising JavaScript names and prevent exotic identifiers from retaining their intended spelling.
Instead, the implementation separates source-path identity from the generated JavaScript name:
.cmjmetadata stores the exact source path as a list of segments.Consumers therefore look up hoisted exports using the structural source path, while the generated JavaScript remains readable and predictable.
If two hoisted paths produce the same JavaScript export name, or if that name conflicts with an existing top-level binding, compilation fails with a clear error.
.cmjMetadataThe
.cmjformat stores each hoisted export as:For example,
A.B.makeis represented as:{ path: ["A", "B", "make"]; export_name: "A$B$make"; }The path is used for exact source-level lookup. The export name is the compiler identifier used for the flat JavaScript export.
This metadata remains separate from the regular
valuestable, which continues to hold arity and cross-module optimization information. Because adding this metadata changes the marshaled.cmjschema, the compiler compatibility marker is bumped toCaml1999I024, ensuring stale compiled artifacts are rebuilt after an upgrade.Consumer Lookup
When compiling a cross-module nested read such as:
normal compilation looks up the first field,
A, in the producer’s.cmjand emits the remaining property accesses:For a nested read, the compiler now also reconstructs the exact source path and checks the producer’s hoisted export metadata.
If the path is present, it uses the recorded flat export name:
Otherwise, it falls back to the normal property chain.
Because lookup uses the structural path rather than a
$-joined key, exotic identifiers cannot accidentally resolve to another binding’s hoisted export.Performance
Compilation units without registered hoisted functions skip alias collection immediately.
For annotated functions, the compiler indexes the existing Lambda groups and resolves each recorded source path against the final exported module structure. It also verifies that the path still refers to the exact annotated binding, so a function hidden by a signature or replaced by a shadowing binding is not aliased. This is compile-time only and proportional to the module output and the normally short paths involved.
For each annotated function, the generated JavaScript contains one additional alias assignment and export. Calls use the flat export directly; there is no runtime path lookup or encoding.
Consumer lookup is compile-time only and scans the dependency’s normally very small list of hoisted exports.
Tests
Adds coverage for:
$identifiers;.resifiles;