Repository navigation
Map TypeCheckErrorKind to official errorCodes #81
Description
Part of #74 (Phase 1). The cheapest item in the plan: TypeCheckErrorKind already distinguishes every case needed, but error_code() returns None for all but two, so 153 corpus cases are unmeasurable.
Do now — no semantic risk
| Kind | Code | Corpus cases |
|---|---|---|
TypeMismatch |
TypesDoNotUnify |
41 |
OccursCheck |
InfiniteType |
2 |
IntegerOutOfRange |
IntOutOfRange |
1 |
NoInstance |
NoInstanceFound |
53 |
OverlappingInstances |
OverlappingInstances |
8 |
MissingInstanceMethod |
MissingClassMember |
2 |
EscapedSkolem and InvalidCoercibleInstanceDeclaration are already mapped.
Need a purs semantics decision first
UnconstrainedType(emitted atcrates/psrs-typecheck/src/typecheck/unify.rs:314androws.rs:217for "cannot infer a monomorphic type") — compare againstpurs'WildcardInferredType(a warning) andCannotApplyExpressionOfTypeOnType. Do not guess; readpursand pick.AmbiguousConstraint(classes/fundeps.rs:293) — compare againstAmbiguousTypeVariablesandUnconstrainedTypeVariable.FundepConflict— compare againstFunctionalDependencyError/ the fundep diagnostics in the corpus.
Note
crates/psrs-driver/src/tests/coercion.rs:7 currently accepts a NoInstanceFound assertion by falling back to a message-text match, precisely because the code is absent. Tighten that helper once the code exists; a message-text fallback in a test is a hidden gap.
Acceptance
error_code() covers every kind that has an unambiguous official code, coercion.rs matches on codes only, and the L4/L5 scoreboards report a non-zero baseline for TypesDoNotUnify and NoInstanceFound.
References
crates/psrs-typecheck/src/typecheck/error.rsdocs/design/D-04-suite-roadmap.md— M4, M5 suite lists
Activity
biuld commentedon Oct 2, 2026
Landed in #110. The six mappings are in, and the three that needed a
pursdecision are decided from the source, not guessed.Mapped:
TypeMismatch→TypesDoNotUnify,OccursCheck→InfiniteType,IntegerOutOfRange→IntOutOfRange,NoInstance→NoInstanceFound,MissingInstanceMethod→MissingClassMember,AmbiguousConstraint→AmbiguousTypeVariables.Decided against mapping, with the reading:
UnconstrainedType— I checked 0.15.16 on seven programs.purshas no error for an undetermined monomorphic variable: it generalizes the variable or reports the mismatch that left it unsolved. The issue's suggestedWildcardInferredTypeis wrong twice over — it is a warning about a wildcard, not an error about a determined variable, and it fires while the variable is still solvable. Left unmapped; the honest code is whicheverTypesDoNotUnifyorUndefinedTypeVariableapplies.FundepConflict— there is noFunctionalDependencyErrorinErrors.hsat all.pursreports the consequence:RowInInstanceNotDetermined0/1expectInvalidInstanceHead, raised inTypeChecker.checkTypeClassInstancefor exactly this shape. A two-instance program confirms it —pursanswersOverlappingInstances.AmbiguousConstraint— mapped, with the stage difference recorded on the function.pursthrowsAmbiguousTypeVariablesinTypeChecker/Types.hswith the same set of undetermined variables, but at generalization rather than while solving a goal.The hidden gap is closed:
coercion.rsno longer falls back to a message-text match forNoInstanceFound. That test was passing for the wrong reason.The acceptance's baseline is met: L4 reports a non-zero
TypesDoNotUnify(10/32) and L5 a non-zeroNoInstanceFound(28/36). Full numbers in D-04 and #110.Note on issue ordering
This was #81, but the L4/L5 scoreboards the acceptance refers to are #82's deliverable, so this change carries both:
check_program_types_lenientandl4_l5_scoreboard_with_annotationsland here alongside the mappings. Splitting them would have left one half unmeasurable — a mapping with no board reports nothing, and a board with no mappings measures a compiler that cannot emit codes.feat(typecheck): map the official errorCodes and add a lenient type c…