[cknitt]

Fixes #9150.

The value restriction (Typecore.is_nonexpansive) treats a record literal as non-expansive when none of its fields is mutable. An empty literal {} of an all-optional record has no field entries in the typed tree, so the check always passed. Its type variables were then generalized even when the record has a mutable field, and a value could be stored at one type and read at another:

type cell<'a> = {tag?: int, mutable value?: 'a}
let cell: cell<_> = {}
cell.value = Some(1)
let s: option<string> = cell.value // compiled; `s` held the number 1

For {} without a spread, the check now looks up the record's declaration through the expression's type and requires every field to be immutable. {} of an immutable record still generalizes.

The new super_errors fixture record_empty_mutable_does_not_generalize.res covers both: it first uses an immutable {} at two types, then reaches the expected error for the mutable one.

#9149, which stopped storing omitted optional fields in the typed tree, added the matching check for literals that write some fields but leave out a mutable one. This PR fills in the remaining {} arm of that check.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Kbf3gKyiYMf54wPRxFdUWe

[github-actions]

Changelog

🐛 Bug fix

• Stop generalizing the type of an empty record literal {} whose record has a mutable field, which let a value be stored at one type and read at another.

Semantic Diff

1 commit · Full page

Treat an empty record literal with mutable fields as expansive

_{d0537fc · cknitt + Claude · Oct 31, 2026, 08:21 UTC}

Why

The value restriction looks for mutable fields among a record literal's entries, but {} of an all-optional record has none, so it was always non-expansive and its type variables were generalized even when a field is mutable (#9150). It now looks up the record's declaration and requires every field to be immutable.

Diagnostic added (empty record literal with a mutable field)

type cell<'a> = {tag?: int, mutable value?: 'a}
let cell: cell<_> = {}
cell.value = Some(1)
let s: option<string> = cell.value

diagnostic

-none; `s` holds the number 1 at run time
+This has type: option<int>
+But it's expected to have type: option<string>
+
+The incompatible parts:
+  int vs string

Review

• Does {} of an immutable record still generalize? Yes; the super_errors fixture uses one such value at both option<int> and option<string> before reaching the error.

[codecov]

Codecov Report

❌ Patch coverage is 80.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 81.74%. Comparing base (940b761) to head (d0537fc).

Files with missing lines	Patch %	Lines
compiler/ml/typecore.ml	80.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #9152      +/-   ##
==========================================
- Coverage   81.74%   81.74%   -0.01%     
==========================================
  Files         460      460              
  Lines       64940    64944       +4     
==========================================
+ Hits        53088    53091       +3     
- Misses      11852    11853       +1     

Files with missing lines	Coverage Δ
compiler/ml/typecore.ml	89.18% <80.00%> (-0.03%)	⬇️

🚀 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]

Open in StackBlitz

rescript

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

@rescript/belt

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

@rescript/darwin-arm64

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

@rescript/linux-arm64

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

@rescript/linux-x64

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

@rescript/runtime

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

@rescript/win32-x64

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

commit: d0537fc

[github-actions]

Developer playground preview: https://rescript-lang.github.io/rescript/dev-playground/?version=pr-9152

[cknitt]

@codex review

[chatgpt-codex-connector]

Codex Review Summary

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

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-31T10:08:16.666815Z	d0537fc	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]

Codex Review: Didn't find any major issues. 🎉

Reviewed commit: d0537fc9fd

ℹ️ 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".

[cristianoc]

Please check for potential breaking changes.
This is bug fix so it's fine no matter what.
But one should set expectaions right.

[cknitt]

Checked: master and this PR, each with the same files.

What newly fails. All three conditions must hold:

1. an empty literal {};
2. a record type whose fields are all optional, with at least one mutable field;
3. a type parameter that the binding leaves open.

The binding's type then gets a weak variable instead of being generalized. That surfaces in three ways:

type handlers<'a> = {mutable onChange?: 'a => unit}

// 1. Left open at the top level:
let empty: handlers<'a> = {}
// error: type variables that cannot be generalized: handlers<'_a>

// 2. Used at two types:
let empty: handlers<_> = {}
let forInts: handlers<int> = empty
let forStrings: handlers<string> = empty // error: handlers<int> vs handlers<string>

// 3. Declared polymorphic in a .resi as `let empty: handlers<'a>`:
//    error: the implementation has handlers<'_weak1>

All three compile on master. Cases 2 and 3 are exactly the unsound pattern: one mutable object shared at several types.

What still compiles:

• a concrete type: let forInts: handlers<int> = {}
• an open type that one use in the module fixes
• a function let make = (): handlers<'a> => {}, used at several types
• records without type parameters
• {} of immutable records, which still generalizes, as the new fixture checks
• any literal with at least one field written (unchanged)

Migration: make the shared value a function (let empty = () => {}), or give it a concrete type. I've spelled this out in the changelog fragment (6730acc).

In this repo nothing hit it: the stdlib, Belt, the tests and the rewatch test repo with its dependencies all build unchanged. Records with optional mutable fields and type parameters are rare, so I'd expect very little breakage outside.