Repository navigation
Match fields and constructors by name in signature mismatch errors - #9133
Conversation
Changelog💅 Polish
Semantic Diff1 commit · Full page Match fields and constructors by name in signature mismatch errors98ff97a · cknitt + Claude · Oct 30, 2026, 06:44 UTC
Includecore.align lines the two lists up by name. Declarations with the same names in the same order, as nearly all are, are paired directly. Otherwise a name in only one declaration is missing or extra, one name lacking on each side after the same common entry is a renaming (paired in order when that gap holds as many on each side), and common names in another order are reported once, in the expected order. Each entry in both is compared on its own, at its own position in each variant layout, so every difference is reported. The differences of an inline record are grouped under its constructor. The declarations are printed as before; the blocks below show the reasons under them. Diagnostic modified (field missing in the middle) module M: {
type t = {name: string, age: int, email: string}
} = {
type t = {name: string, email: string}
}
-Fields number 2 have different names, email and age.
+The field age is only present in the expected declaration.Diagnostic modified (fields in another order) module M: {
type t = {a: int, b: int, c: int, d: int}
} = {
type t = {c: int, a: int, b: int, e: int}
}
-Fields number 1 have different names, c and a.
+The field d is only present in the expected declaration.
+The field e is only present in the actual declaration.
+The fields are in another order in the expected declaration:
+a, b, c.Diagnostic modified (several differing fields) module M: {
type t = {id: int, mutable name: string, age: int, @as("e-mail") email?: string}
} = {
type t = {id: string, name: string, age: float, email: string}
}
+The types for field id are not equal.
The mutability of field name is different.
+The types for field age are not equal.
+The optional attribute of field email is different.
+The field email has the runtime name "email" in the actual declaration,
+but "e-mail" in the expected declaration.Diagnostic modified (constructor added and renamed) module M: {
type t = Red | Green | Blue | Gray
} = {
type t = Black | Red | Green | Blue | Grey
}
-Constructors number 1 have different names, Black and Red.
+The constructor Grey is named Gray in the expected declaration.
+The constructor Black is only present in the actual declaration.Diagnostic modified (inline record of a constructor) module M: {
type t = Person({name: string, age: int}) | Anonymous
} = {
type t = Person({age: int, name: string, nick: string}) | Anonymous
}
-Fields number 0 have different names, age and name.
+The records of constructor Person differ:
+ The field nick is only present in the actual declaration.
+ The fields are in another order in the expected declaration:
+ name, age.Review
|
f1f3d46 to
d96aea3
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## print-type-annotations #9133 +/- ##
==========================================================
+ Coverage 81.70% 81.73% +0.03%
==========================================================
Files 460 460
Lines 64877 64936 +59
==========================================================
+ Hits 53008 53076 +68
+ Misses 11869 11860 -9
🚀 New features to boost your workflow:
|
rescript
@rescript/belt
@rescript/darwin-arm64
@rescript/linux-arm64
@rescript/linux-x64
@rescript/runtime
@rescript/win32-x64
commit: |
|
Developer playground preview: https://rescript-lang.github.io/rescript/dev-playground/?version=pr-9133 |
d96aea3 to
db837db
Compare
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Codex Review: Didn't find any major issues. 🎉 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". |
Why:
The inclusion check compared the fields of two records and the
constructors of two variants by position and reported only the first
difference. A field missing in the middle, two swapped fields or a
constructor added at the front all read as "Fields number N have
different names", and the other differences stayed hidden. Upstream
OCaml 4.13 lines the declarations up with an edit distance (#9130);
names are unique within a declaration, so lining them up by name is
enough here.
Includecore.align lines the two lists up by name. Declarations with the same
names in the same order, as nearly all are, are paired directly. Otherwise a
name in only one declaration is missing or extra, one name lacking on each
side after the same common entry is a renaming (paired in order when that gap
holds as many on each side), and common names in another order are reported
once, in the expected order. Each entry in both is compared on its own, at its
own position in each variant layout, so every difference is reported. The
differences of an inline record are grouped under its constructor.
The declarations are printed as before; the blocks below show the reasons
under them.
Diagnostic modified (field missing in the middle):
Example:
module M: {
type t = {name: string, age: int, email: string}
} = {
type t = {name: string, email: string}
}
Before (diagnostic):
Fields number 2 have different names, email and age.
After (diagnostic):
The field age is only present in the expected declaration.
Diagnostic modified (fields in another order):
Example:
module M: {
type t = {a: int, b: int, c: int, d: int}
} = {
type t = {c: int, a: int, b: int, e: int}
}
Before (diagnostic):
Fields number 1 have different names, c and a.
After (diagnostic):
The field d is only present in the expected declaration.
The field e is only present in the actual declaration.
The fields are in another order in the expected declaration:
a, b, c.
Diagnostic modified (several differing fields):
Example:
module M: {
type t = {id: int, mutable name: string, age: int, @as("e-mail") email?: string}
} = {
type t = {id: string, name: string, age: float, email: string}
}
Before (diagnostic):
The mutability of field name is different.
After (diagnostic):
The types for field id are not equal.
The mutability of field name is different.
The types for field age are not equal.
The optional attribute of field email is different.
The field email has the runtime name "email" in the actual declaration,
but "e-mail" in the expected declaration.
Diagnostic modified (constructor added and renamed):
Example:
module M: {
type t = Red | Green | Blue | Gray
} = {
type t = Black | Red | Green | Blue | Grey
}
Before (diagnostic):
Constructors number 1 have different names, Black and Red.
After (diagnostic):
The constructor Grey is named Gray in the expected declaration.
The constructor Black is only present in the actual declaration.
Diagnostic modified (inline record of a constructor):
Example:
module M: {
type t = Person({name: string, age: int}) | Anonymous
} = {
type t = Person({age: int, name: string, nick: string}) | Anonymous
}
Before (diagnostic):
Fields number 0 have different names, age and name.
After (diagnostic):
The records of constructor Person differ:
The field nick is only present in the actual declaration.
The fields are in another order in the expected declaration:
name, age.
Review: Does the check accept anything it rejected before, or the other way round? No. A declaration passes only when every name is in both, in the same order, with no difference per entry, which is what the positional walk required; only the messages change.
Review: Why is the type of an optional field not reported when only its optional attribute differs? The type of an optional field is an option of the declared type, so it differs whenever the attribute does; the attribute message already says so.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Kbf3gLpf7RN1MiRcubPgRn
Signed-off-by: Christoph Knittel <ck@cca.io>
db837db to
98ff97a
Compare
|
@codex review |
|
Codex Review: Didn't find any major issues. What shall we delve into next? 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". |
Part of #9130 (diff-based inclusion errors). Stacked on #9136.
Signature mismatch errors compared the fields of two records and the constructors of two variants by position, and stopped at the first difference. A field missing in the middle, swapped fields or a constructor added at the front all came out as "Fields number N have different names", and later differences stayed hidden.
Upstream OCaml 4.13 lines the two declarations up with an edit distance (
Diffing, about 600 lines). Names are unique within a declaration, so this PR lines them up by name instead (Includecore.align):agemissing in the middleBlackadded,GrayrenamedWhich declarations are accepted does not change: only the messages do. Declarations whose names agree, as nearly all do, are paired without building any tables.
New tests:
tests/build_tests/super_errors/fixtures/inclusion_*.res(field missing, renamed, reordered, several differences, constructor added and renamed, constructors reordered, inline record).Field order itself stays significant: it decides the evaluation order of record literals, so reordered records keep being an error, now with a clear message. Whether variant constructors could be reordered freely is a separate question for #9130.
🤖 Generated with Claude Code
https://claude.ai/code/session_01Kbf3gLpf7RN1MiRcubPgRn