Skip to main content
Next (unreleased) · docs c218d875 · core f63c1e69 · built 2026-10-26 22:39 UTC

Inference-time type lookup falls back to a name-approximate, cross-module search

Limitation​

The typed IR does not carry a declaration's SymbolId on every type spelling that inference and the checks around it see. Where a value's Type::Named spelling has no reliable module context (for example a value that arrived through a function return), TypeDefinitionRegistry::resolve_type_key_broad accepts "a bare declared name from any module" as a last resort. About twenty call sites use it: field access and visibility checks, enum info, method and scheme lookup, and constraint-solving hooks. Its own comment says this is the pre-#1060 name-keyed behaviour, kept "until the id rides on the typed node" and cites metel-core#1052, which is now closed; the id has not yet been threaded through these sites.

Impact​

Two modules that declare a type with the same name can be confused. Reproduced against current develop: with a::Item { x } and b::Item { y }, field access on a value returned from a::make() fails with T0003 (no field xonItem``) once b is also imported, while the same program passes when only a is imported. The symptom is tracked as metel-core#1222.

This does not contradict arch.resolution.requirement-1, which is scoped to phases after inference has solved a body and the resolution is frozen; the fallback lives in the inference-time registry, before that freeze.

Affects​

Resolution​

None yet. Removing the fallback means carrying the declaration id on the typed IR's type spellings; the user-visible bug is metel-core#1222.