1- # CLAUDE .md
1+ # AGENTS .md
22
3- This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
3+ This file provides guidance to AI coding assistants when working with code in this repository.
44
5- ## Project Overview
5+ ## Quick Start: Essential Commands
66
7- This is the ReScript compiler repository - a robustly typed language that compiles to efficient and human-readable JavaScript. ReScript is built using OCaml and includes a complete toolchain with compiler, build system, syntax parser, and standard library.
7+ ``` bash
8+ # Build and test
9+ make && make test
10+
11+ # Format and check code
12+ make format && make checkformat
13+ ```
14+
15+ ## Critical Compiler Guidelines
16+
17+ ### ⚠️ Critical Guidelines & Common Pitfalls
18+
19+ - ** Do not introduce new keywords unless absolutely necessary** - Try to find ways to implement features without reserving keywords, as seen with the "catch" implementation that avoids making it a keyword.
20+
21+ - ** We are NOT bound by OCaml compatibility** - The ReScript compiler originated as a fork of the OCaml compiler, but we maintain our own AST and can make breaking changes. Focus on what's best for ReScript's JavaScript compilation target.
22+
23+ - ** Never modify ` parsetree0.ml ` ** - Existing PPX (parser extensions) rely on this frozen v0 version. When changing ` parsetree.ml ` , always update the mapping modules ` ast_mapper_from0.ml ` and ` ast_mapper_to0.ml ` to maintain PPX compatibility while allowing the main parsetree to evolve
24+
25+ - ** Be careful with similar constructor names across different IRs** - Note that ` Lam ` (Lambda IR) and ` Lambda ` (typed lambda) have variants with similar constructor names like ` Ltrywith ` , but they represent different things in different compilation phases.
26+
27+ - ** Avoid warning suppressions** - Never use ` [@@warning "..."] ` to silence warnings. Instead, fix the underlying issue properly
28+
29+ - ** Missing test coverage** - Always add tests for syntax, lambda, and end-to-end behavior
830
9- ## Build Commands
31+ - ** Test early and often ** - Add tests immediately after modifying each compiler layer to catch problems early, rather than waiting until all changes are complete
1032
11- ### Basic Development
33+ - ** Use underscore patterns carefully** - Don't use ` _ ` patterns as lazy placeholders for new language features that then get forgotten. Only use them when you're certain the value should be ignored for that specific case. Ensure all new language features are handled correctly and completely across all compiler layers
34+
35+ ## Compiler Architecture
36+
37+ ### Compilation Pipeline
38+
39+ ```
40+ ReScript Source (.res)
41+ ↓ (ReScript Parser - compiler/syntax/)
42+ Surface Syntax Tree
43+ ↓ (Frontend transformations - compiler/frontend/)
44+ Surface Syntax Tree
45+ ↓ (OCaml Type Checker - compiler/ml/)
46+ Typedtree
47+ ↓ (Lambda compilation - compiler/core/lam_*)
48+ Lambda IR
49+ ↓ (JS compilation - compiler/core/js_*)
50+ JS IR
51+ ↓ (JS output - compiler/core/js_dump*)
52+ JavaScript Code
53+ ```
54+
55+ ### Key Directory Structure
56+
57+ ```
58+ compiler/
59+ ├── syntax/ # ReScript syntax parser (MIT licensed)
60+ ├── frontend/ # AST transformations, FFI processing
61+ ├── ml/ # OCaml compiler infrastructure
62+ ├── core/ # Core compilation (lam_*, js_* files)
63+ ├── ext/ # Extended utilities and data structures
64+ ├── bsb/ # Legacy build system
65+ └── gentype/ # TypeScript generation
66+
67+ analysis/ # Language server and tooling
68+ packages/@rescript/
69+ ├── runtime/ # Runtime and standard library
70+ └── <platform>/ # Platform-specific binaries
71+
72+ tests/
73+ ├── syntax_tests/ # Parser/syntax layer tests
74+ ├── tests/ # Runtime library tests
75+ ├── build_tests/ # Integration tests
76+ └── ounit_tests/ # Compiler unit tests
77+ ```
78+
79+ ## Working on the Compiler
80+
81+ ### Development Workflow
82+
83+ 1 . ** Understand which layer you're working on:**
84+ - ** Syntax layer** (` compiler/syntax/ ` ): Parsing and surface syntax
85+ - ** ML layer** (` compiler/ml/ ` ): Type checking and AST transformations
86+ - ** Lambda layer** (` compiler/core/lam_* ` ): Intermediate representation and optimizations
87+ - ** JS layer** (` compiler/core/js_* ` ): JavaScript generation
88+
89+ 2 . ** Always run appropriate tests:**
90+ ``` bash
91+ # For compiler or stdlib changes
92+ make test
93+
94+ # For syntax changes
95+ make test-syntax
96+
97+ # For specific test types
98+ make test-syntax-roundtrip
99+ make test-gentype
100+ make test-analysis
101+ ```
102+
103+ 3 . ** Test your changes thoroughly:**
104+ - Syntax tests for new language features
105+ - Integration tests for behavior changes
106+ - Unit tests for utility functions
107+ - Always check JavaScript output quality
108+
109+ ### Debugging Techniques
110+
111+ #### View Intermediate Representations
12112``` bash
13- # Build compiler and copy executables
113+ # Source code (for debugging preprocessing)
114+ ./cli/bsc.js -dsource myfile.res
115+
116+ # Parse tree (surface syntax after parsing)
117+ ./cli/bsc.js -dparsetree myfile.res
118+
119+ # Typed tree (after type checking)
120+ ./cli/bsc.js -dtypedtree myfile.res
121+
122+ # Raw lambda (unoptimized intermediate representation)
123+ ./cli/bsc.js -drawlambda myfile.res
124+
125+ # Use lambda printing for debugging (add in compiler/core/lam_print.ml)
126+ ```
127+
128+ #### Common Debug Scenarios
129+ - ** JavaScript formatting issues** : Check ` compiler/ml/pprintast.ml `
130+ - ** Type checking issues** : Look in ` compiler/ml/ ` type checker modules
131+ - ** Optimization bugs** : Check ` compiler/core/lam_*.ml ` analysis passes
132+ - ** Code generation bugs** : Look in ` compiler/core/js_*.ml ` modules
133+
134+ ### Testing Requirements
135+
136+ #### When to Add Tests
137+ - ** Always** for new language features
138+ - ** Always** for bug fixes
139+ - ** When modifying** analysis passes
140+ - ** When changing** JavaScript generation
141+
142+ #### Test Types to Include
143+ 1 . ** Syntax tests** (` tests/syntax_tests/ ` ) - Parser validation
144+ 2 . ** Integration tests** (` tests/tests/ ` ) - End-to-end behavior
145+ 3 . ** Unit tests** (` tests/ounit_tests/ ` ) - Compiler functions
146+ 4 . ** Build tests** (` tests/build_tests/ ` ) - Error cases and edge cases
147+ 5 . ** Type tests** (` tests/build_tests/super_errors/ ` ) - Type checking behavior
148+
149+ ## Build Commands & Development
150+
151+ ### Essential Commands
152+ ``` bash
153+ # Build compiler
14154make
15155
16- # Build in watch mode
156+ # Build compiler in watch mode
17157make watch
18158
19- # Build everything including standard library
159+ # Build compiler and standard library
20160make lib
21161
162+ # Build compiler and standard library and run all tests
163+ make test
164+
22165# Build artifacts and update artifact list
23166make artifacts
167+
168+ # Clean build
169+ make clean
24170```
25171
26- ### Testing
172+ ### Testing Commands
27173``` bash
28- # Run all tests
29- make test
30-
31- # Run specific test types
174+ # Specific test types
32175make test-syntax # Syntax parser tests
33- make test-syntax-roundtrip # Roundtrip syntax tests
176+ make test-syntax-roundtrip # Roundtrip syntax tests
34177make test-gentype # GenType tests
35178make test-analysis # Analysis tests
36179make test-tools # Tools tests
37180make test-rewatch # Rewatch tests
38181
39- # Run single file test
40- ./cli/bsc.js myTestFile.res
41-
42- # View parse/typed trees for debugging
43- ./cli/bsc.js -dparsetree myTestFile.res
44- ./cli/bsc.js -dtypedtree myTestFile.res
182+ # Single file debugging
183+ ./cli/bsc.js myfile.res
45184```
46185
47186### Code Quality
@@ -60,80 +199,61 @@ npm run check:all
60199npm run typecheck
61200```
62201
63- ### Clean Operations
64- ``` bash
65- make clean # Clean OCaml build artifacts
66- make clean-all # Clean everything including Rust/gentype
67- ```
68-
69- ## Compiler Architecture
70-
71- The ReScript compiler follows this high-level pipeline:
72-
73- ```
74- ReScript Source (.res)
75- ↓ (ReScript Parser - compiler/syntax/)
76- Surface Syntax Tree
77- ↓ (Frontend transformations - compiler/frontend/)
78- Surface Syntax Tree
79- ↓ (OCaml Type Checker - compiler/ml/)
80- Typedtree
81- ↓ (Lambda compilation - compiler/core/lam_*)
82- Lambda IR
83- ↓ (JS compilation - compiler/core/js_*)
84- JS IR
85- ↓ (JS output - compiler/core/js_dump*)
86- JavaScript Code
87- ```
88-
89- ### Key Directories
90202
91- - ** ` compiler/syntax/ ` ** - ReScript syntax parser (MIT licensed, separate from main LGPL)
92- - ** ` compiler/frontend/ ` ** - AST transformations, external FFI processing, built-in attributes
93- - ** ` compiler/ml/ ` ** - OCaml compiler infrastructure (type checker, typedtree, etc.)
94- - ** ` compiler/core/ ` ** - Core compilation:
95- - ` lam_* ` files: Lambda IR compilation and optimization passes
96- - ` js_* ` files: JavaScript IR and code generation
97- - ** ` compiler/ext/ ` ** - Extended utilities and data structures
98- - ** ` compiler/bsb/ ` ** - Build system implementation
99- - ** ` compiler/gentype/ ` ** - TypeScript generation
100- - ** ` runtime/ ` ** - ReScript standard library (written in ReScript)
101- - ** ` lib/ ` ** - Compiled JavaScript output of standard library
102- - ** ` analysis/ ` ** - Language server and tooling support
203+ ## Performance Considerations
103204
104- ### Build System Components
205+ The compiler is designed for fast feedback loops and scales to large codebases:
105206
106- - ** ` compiler/bsb_exe/ ` ** - Main ReScript build tool entry point
107- - ** ` compiler/bsc/ ` ** - Compiler binary entry point
108- - ** ` rewatch/ ` ** - File watcher (written in Rust)
109- - ** ` ninja/ ` ** - Vendored Ninja build system
110-
111- ## Development Setup Notes
112-
113- - Uses OCaml 5.3.0+ with opam for compiler development
114- - Uses dune as build system with specific profiles (dev, release, browser)
115- - Node.js 20+ required for JavaScript tooling
116- - Rust toolchain needed for rewatch file watcher
117- - Python ≤3.11 required for building ninja
207+ - ** Avoid meaningless symbols** in generated JavaScript
208+ - ** Maintain readable JavaScript output**
209+ - ** Consider compilation speed impact** of changes
210+ - ** Use appropriate optimization passes** in Lambda and JS IRs
211+ - ** Profile** before and after performance-related changes
118212
119213## Coding Conventions
120214
215+ ### Naming
121216- ** OCaml code** : snake_case (e.g., ` to_string ` )
122217- ** ReScript code** : camelCase (e.g., ` toString ` )
123- - Use DCO sign-off for all commits: ` Signed-Off-By: Your Name <email> `
124-
125- ## Testing Strategy
126218
127- - ** Mocha tests** (` tests/tests/ ` ) - Runtime library unit tests
128- - ** Build system tests** (` tests/build_tests/ ` ) - Integration tests
129- - ** OUnit tests** (` tests/ounit_tests/ ` ) - Compiler unit tests
130- - ** Expectation tests** - Plain ` .res ` files that check compilation output
131- - Always include appropriate tests with new features/changes
219+ ### Commit Standards
220+ - Use DCO sign-off: ` Signed-Off-By: Your Name <email> `
221+ - Include appropriate tests with all changes
222+ - Build must pass before committing
132223
133- ## Performance Notes
134-
135- The compiler is designed for fast feedback loops and scales to large codebases. When making changes:
136- - Avoid introducing meaningless symbols
137- - Maintain readable JavaScript output
138- - Consider compilation speed impact
139- - Use appropriate optimization passes in the Lambda and JS IRs
224+ ### Code Quality
225+ - Follow existing patterns in the codebase
226+ - Prefer existing utility functions over reinventing
227+ - Comment complex algorithms and non-obvious logic
228+ - Maintain backward compatibility where possible
229+
230+ ## Development Environment
231+
232+ - ** OCaml** : 5.3.0+ with opam
233+ - ** Build System** : dune with profiles (dev, release, browser)
234+ - ** JavaScript** : Node.js 20+ for tooling
235+ - ** Rust** : Toolchain needed for rewatch
236+ - ** Python** : 3 required for building ninja
237+
238+ ## Common Tasks
239+
240+ ### Adding New Language Features
241+ 1 . Update parser in ` compiler/syntax/ `
242+ 2 . Update AST definitions in ` compiler/ml/ `
243+ 3 . Implement type checking in ` compiler/ml/ `
244+ 4 . Add Lambda IR handling in ` compiler/core/lam_* `
245+ 5 . Implement JS generation in ` compiler/core/js_* `
246+ 6 . Add comprehensive tests
247+
248+ ### Debugging Compilation Issues
249+ 1 . Identify which compilation phase has the issue
250+ 2 . Use appropriate debugging flags (` -dparsetree ` , ` -dtypedtree ` )
251+ 3 . Check intermediate representations
252+ 4 . Add debug output in relevant compiler modules
253+ 5 . Verify with minimal test cases
254+
255+ ### Working with Lambda IR
256+ - Remember Lambda IR is the core optimization layer
257+ - All ` lam_*.ml ` files process this representation
258+ - Use ` lam_print.ml ` for debugging lambda expressions
259+ - Test both with and without optimization passes
0 commit comments