[cknitt]

Fixes #8964. Stacked on #8950, whose stored type shapes it reads.

Interface inclusion ignored @notUndefined. An interface could declare @notUndefined type t over type t = option<int>, and clients then unboxed option<t>, so Some(M.none) was None.

Now, when an interface (or a functor parameter, or the original of a with type constraint) declares a type @notUndefined, its implementation must be a type that cannot hold undefined. The rule is the one option unboxing uses: a record, a builtin type other than option/unit, an annotated or @notUndefined type, and so on. An implementation whose representation the compiler does not see is accepted too, because it has none to contradict the claim: an abstract type, also through an abbreviation such as type t = Dom.element, or a JavaScript object type. The stdlib's Lazy.res (type t<+'a> under @notUndefined in Lazy.resi) relies on that, and so do bindings. The type of a functor parameter or a locally abstract type stands for any type and does not count as abstract.

Type declarations do not match:
  type t = option<int>
is not included in
  type t
Their runtime representations differ:
the second declaration is @notUndefined,
but the first declaration can hold undefined.

The check sits in Includemod.type_declarations, which every inclusion goes through, because Typeopt depends on Includecore through Typedecl. UntaggedVariants.md rule 13 now states it.

New tests: super_errors_multi/Cross_not_undefined_option_implementation (the issue's repro), super_errors/not_undefined_functor_argument and not_undefined_functor_parameter, and tests/tests/src/not_undefined_interface_test.res (an abbreviation of an abstract type and an object type, accepted).

🤖 Generated with Claude Code

https://claude.ai/code/session_01Fc7LEuyEfynjaKCVEBPmTF

[cknitt]

@codex review

[codecov]

Codecov Report

❌ Patch coverage is 87.50000% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.31%. Comparing base (31a67fe) to head (743b80b).
⚠️ Report is 2 commits behind head on instanceof-typeof-annotations.

Files with missing lines	Patch %	Lines
compiler/ml/includemod.ml	86.66%	2 Missing ⚠️

Additional details and impacted files

@@                      Coverage Diff                       @@
##           instanceof-typeof-annotations    #8966   +/-   ##
==============================================================
  Coverage                          81.31%   81.31%           
==============================================================
  Files                                456      456           
  Lines                              64130    64145   +15     
==============================================================
+ Hits                               52148    52161   +13     
- Misses                             11982    11984    +2     

Files with missing lines	Coverage Δ
compiler/ml/includecore.ml	79.06% <100.00%> (+0.07%)	⬆️
compiler/ml/includemod.ml	76.30% <86.66%> (+0.42%)	⬆️

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

[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	🔄 Running since 2026-10-23T11:48:15.038351Z	b19d240	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.

[pkg-pr-new]

Open in StackBlitz

rescript

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

@rescript/belt

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

@rescript/darwin-arm64

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

@rescript/linux-arm64

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

@rescript/linux-x64

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

@rescript/runtime

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

@rescript/win32-x64

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

commit: ecc1ff2

[cknitt]

@codex review

[github-actions]

Changelog

🐛 Bug fix

• Reject an implementation that can hold undefined for a type its interface declares @notUndefined, which made Some(None) of the type None in clients.

Semantic Diff

3 commits · Full page

✨ Simplify the payload kinds and untagged checks

_{31a67fe · Christoph Knittel + Claude · Oct 24, 2026, 09:16 UTC · new}

Why

The architecture review found the same knowledge in several places: three tables of typeof names, an IntType/FloatType distinction that no consumer made, two functions for @unboxed, two checks of the arity of untagged constructors, and the opaque-abstract-type test written inline.

Variant_runtime lists the kinds typeof recognizes once, and the names, the reverse lookup and the generated typeof strings come from it. int and float payloads have one kind, NumberType. has_untagged replaces its twin, the layout alone reports a constructor with more than one argument, now at the constructor, and Variant_layout.abstractness says whether an abstract type can be refined. resolve_shapes stops when a round changes nothing, type_cannot_contain_undefined no longer re-reads a shape it has read, and the doc of type_shape and rule 14 say what the shape holds and how classes compare.

Diagnostic modified (more than one argument)

@unboxed
type t = A(int, int) | B(string)

diagnostic

-UntaggedConstructorMoreThanOneArg.res:2:1-32
+UntaggedConstructorMoreThanOneArg.res:2:10-20

Check @notUndefined of an interface against the implementation

_{b767069 · cknitt + Claude · Oct 22, 2026, 19:04 UTC}

Why

Interface inclusion ignored @notUndefined. An interface could declare @notUndefined type t over type t = option<int>, and clients then unboxed option<t>, so Some(M.none) was None (#8964).

When the second declaration of an inclusion is @notUndefined, the first must be a type that cannot hold undefined, by the rule option unboxing uses, or an abstract type, which has no representation to contradict it. This covers .resi files, functor arguments and with type constraints. The check runs in Includemod, since Typeopt depends on Includecore through Typedecl.

Diagnostic added

// Hidden.resi
@notUndefined type t
// Hidden.res
type t = option<int>

diagnostic · After

Type declarations do not match:
  type t = option<int>
is not included in
  type t
Their runtime representations differ:
the second declaration is @notUndefined,
but the first declaration can hold undefined.

Review

• Why accept an abstract implementation without the attribute? The stdlib's Lazy.res declares type t<+'a> under @notUndefined in its interface, and so may bindings; such a type has no representation that could hold undefined, so requiring the attribute twice would only break them.

Accept @notUndefined over implementations the compiler cannot see into

_{743b80b · cknitt + Claude · Oct 23, 2026, 11:34 UTC}

Why

The check rejected bindings that are fine: an interface's @notUndefined type t over type t = Dom.element, an abbreviation of an abstract type, or over a JavaScript object type, which is never undefined.

An implementation whose representation the compiler does not see has none that contradicts the interface: an abstract type, also reached through an abbreviation, or a JavaScript object type. A functor parameter's or a locally abstract type stands for any type and does not count as abstract.

Diagnostic removed (an abbreviation of an abstract type)

// A.resi
@notUndefined type t
// A.res
type t = Dom.element

diagnostic · Before

Their runtime representations differ:
the second declaration is @notUndefined,
but the first declaration can hold undefined.

[cknitt]

Folded into #8950: the @notUndefined inclusion check reads the stored type_shape of #8950 and lands with it. GitHub shows this PR as merged because #8950's branch now contains its commits; nothing reached master. #8964 is fixed by #8950.