Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Coercion hint suggests the inner type when the mismatch is nested

Open Beginner friendly
  • Is something wrong?
#9,037 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
75/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
ocaml
Domain
compilers

Research direction

The fix is in compiler/ml/error_message_utils.ml: locate where the coercion hint is built from target_type and change it to use top_level_types. Compile the ReScript snippet from the issue to reproduce the wrong hint. Done when the suggested coercion is (make :> unit => iterable<int>) and the example compiles.

Written by the indexing model from the issue text.

Description

When a type mismatch is nested inside another type, the "compatible at runtime" hint suggests a coercion to the inner type instead of the whole expected type, and the suggested code doesn't compile.

let consume = (_f: unit => Iterable.t<int>) => ()
let make: unit => Generator.t<int, unit, unit> = %raw(`function* () { yield 1 }`)
let () = consume(make)

This has type: unit => Generator.t<int, unit, unit>
But this function argument is expecting: unit => Iterable.t<int>

The incompatible parts:
  Generator.t<int, unit, unit> (defined as Generator.t<int, unit, unit>) vs
  Iterable.t<int> (defined as iterable<int>)

Possible solutions:
- These types are compatible at runtime. You can use the coercion operator to convert to the expected type: (make :> iterable<int>)

Applying the suggestion fails with Type unit => Generator.t<int, unit, unit> is not a subtype of iterable<int>. The right suggestion is (make :> unit => iterable<int>), which compiles.

Cause

In compiler/ml/error_message_utils.ml, the hint checks Ctype.subtype on the top-level types of the trace (top_level_types, "Coercion should always target the top level types"), but builds the rewrite from target_type, which is the inner incompatible pair. Printing the top-level expected type instead should fix it.

(The doubled Generator.t<…> (defined as Generator.t<…>) in the same output is #8997.)

Dominant language
OCaml
Stars
7.5k
Forks
483
Avg merge
19h 35m
Merged PRs (30d)
208

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from rescript-lang/rescript

All issues in rescript-lang/rescript

Similar issues

More Compilers issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.