TS backend phase 0 - Typed lambda#8471
Open
cometkim wants to merge 5 commits into
Open
Conversation
![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: 11042863f6
ℹ️ 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".
cometkim
commented
Jun 13, 2026
Comment on lines
+400
to
+405
| ( "-dlamtypes", | ||
| set Clflags.dump_lamtypes, | ||
| "*internal* dump Lam IR type annotations" ); | ||
| ( "-emit-typedefs", | ||
| set Clflags.emit_typedefs, | ||
| "*internal* emit .d.ts declarations" ); |
Member
Author
There was a problem hiding this comment.
This is for debugging purposes, not a complete feature.
Phase 1 should cover the compiler flags and build system integration.
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #8471 +/- ##
==========================================
- Coverage 74.42% 74.20% -0.23%
==========================================
Files 451 453 +2
Lines 61459 61659 +200
==========================================
+ Hits 45743 45755 +12
- Misses 15716 15904 +188
🚀 New features to boost your workflow:
|
This is a split from rescript-lang#8118 and explains the most basic part of the entire work. Therefore, this should provide sufficient explanation to the LLM agents and should not conflict with other backend modifications (e.g., sourcemap) yet. - Before: Gentype; a separated pipeline that parses and reanalyzes serialized type information. - After: Attach the full type information to the Lambda IR and pass it directly to the codegen backend. Although the compiler's intermediate layer still does not use type information, passing through it simplifying the type-related code generation as it can directly access already computed type information without any extra parsing. Next phases: - 1. Implementing dts file emission: Provide it as an additional option. Stabilizes the dts format independently of the existing JS IR and deprecates Gentype. - 2. Rewriting codegen backend entirely: New, fully-typed, well-structured codegen IR that unifies all the fragmented codegen logic. It should covers JS/TS/d.ts in a single path (Need research. It may not be possible or complicated) - Implementation only: JavaScript output - Type only: d.ts output - Implementation + Type: TypeScript output
rescript
@rescript/darwin-arm64
@rescript/darwin-x64
@rescript/linux-arm64
@rescript/linux-x64
@rescript/runtime
@rescript/win32-x64
commit: |
Type annotations on value bindings (`let n: int = 42`) were lost before
reaching the export grouping phase, causing `-emit-typedefs` to emit
`unknown` for all non-function exports.
Root cause: `let n: int = 42` produces `Tpat_alias(Tpat_any, n, ...)`
in the typedtree, not `Tpat_var`. The `for_let` fast path only matched
`Tpat_var`, so annotated bindings fell through to `simple_for_let`,
which does not carry the type through to `Lambda.Llet`.
Fix chain:
- Add `Tpat_alias({pat_desc = Tpat_any}, id, _)` to `for_let` fast path
so `Some pat.pat_type` reaches `Lambda.Llet`
- Add `Types.type_expr option` field to `Lam_group.Single` to carry the
type through `flatten` and `coerce_and_group_big_lambda`
- Thread `~ty` through `Lam_util.refine_let` so reconstructed `Llet`
nodes preserve the annotation after `deep_flatten`
- Capture types in `Lam_stats.export_type_tbl` during `collect_info`
before DCE inlines simple exported constants
- Use `export_type_tbl` in `handle_exports` to pass types to `Single`
when the original `Llet` has been eliminated
- `Lam_ts_emit.emit_decls` reads `ty` from `Single` instead of trying
to recover it from the bound expression
Also fixes the `make_key` regression that caused identical switch arms
to lose action sharing: type metadata in `Lapply.ap_result_type` and
`Llet` fields is now zeroed in sharing keys to prevent false inequality.
Assisted-by: OpenCode:glm-5.2
Member
Author
|
I have verified that all type information, including the module structure, is accessible from the emitter. I will continue emitter changes as phase 1 in another PR. It will be based on the format already investigated in #8118 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a split from #8118 and explains the most basic part of the entire work.
Therefore, this should provide sufficient explanation to the LLM agents and should not conflict with other backend modifications (e.g., sourcemap) yet.
Although the compiler's intermediate layer still does not use type information, passing through it simplifying the type-related code generation as it can directly access already computed type information without any extra parsing.
Next phases: