#9133 Match fields and constructors by name in signature mismatch errors

6176c4d28f138ef3072d465116e5d740939676bd..pr-9133

98ff97a6b · cknitt + Claude · Oct 30, 2026, 06:44 UTC

Match fields and constructors by name in signature mismatch errors

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.

modifiedDiagnostic field missing in the middle

module M: {  type t = {name: string, age: int, email: string}} = {  type t = {name: string, email: string}}

diagnostic

Before

After

Fields number 2 have different names, email and age.The field age is only present in the expected declaration.

modifiedDiagnostic 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}}

diagnostic

Before

After

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.

modifiedDiagnostic 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}}

diagnostic

Before

After

The types for field id are not equal.The mutability of field name is different.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.

modifiedDiagnostic constructor added and renamed

module M: {  type t = Red | Green | Blue | Gray} = {  type t = Black | Red | Green | Blue | Grey}

diagnostic

Before

After

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.

modifiedDiagnostic 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}

diagnostic

Before

After

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

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