uninformative Nim 2.2/devel Error: cannot instantiate H [type declared in /tmp/y.nim(2, 6)], got: <M | M>, but expected: <K> error

[tersec]

Description

y.nim:

import "."/[g, u]
type H[K] = object
proc b(_: int) =  # slightly different, still not useful, error message if `b` generic
  proc r(): H[M] = discard
b(0)

g.nim:

type M* = int

u.nim:

type M* = bool

It's of course easy to spot here, but this is a real issue with a codebase of more than 100k LoC across various libraries.

There are of course ways to try to instantiate the object in a way which will trigger a useful error message, but this isn't one.

Nim Version

Nim Compiler Version 2.2.1 [Linux: amd64]
Compiled at 2025-01-24
Copyright (c) 2006-2025 by Andreas Rumpf

git hash: 12347eae74dbaa0e4dd99691e3a4509e8fe8b265
active boot switches: -d:release

Nim Compiler Version 2.3.1 [Linux: amd64]
Compiled at 2025-01-24
Copyright (c) 2006-2025 by Andreas Rumpf

git hash: d6d28a9c79b1f7d700458ee3aa56a38e1216bb41
active boot switches: -d:release

Current Output

/tmp/y.nim(4, 14) Error: cannot instantiate H [type declared in /tmp/y.nim(2, 6)]
got: <typedesc[M] | typedesc[M]>
but expected: <K>

Expected Output

An error message which helps identify the source of the error more precisely in a larger codebase

Known Workarounds

No response

Additional Information

No response

[metagn]

Since generic instantiation uses sigmatch it's hard to produce the expected ambiguous identifier error here but hopefully something like this would be satisfactory (the : typedesc[M] part could be omitted for type symbols):

/tmp/y.nim(4, 14) Error: cannot instantiate H [type declared in /tmp/y.nim(2, 6)]
got: <g.M: typedesc[M] | y.M: typedesc[M]>
but expected: <K>

This would fix this issue for ambiguous identifiers in normal call arguments too. These already add a message after the fact.

[tersec]

Sure, I agree that would be a reasonable and useful approach. The main thing is to get some hint/clue of what modules or namespaces are providing these symbols, indeed.