Repository navigation
Classify alias.member once during HIR lowering #1952
Description
Warning
This content was written by an AI agent and must be verified by a human developer. After human verification, this alert may be removed.
Summary
alias.member is classified once by the resolver and again in HIR expression lowering. The original ambiguity was fixed earlier (#1722, #1802); what remains is duplicate classification, not a bug.
Proposed direction
Add a resolver API that returns the alias role together with the resolution (a SourcePathResolution), and use it in HIR lowering. Instance members bound in the expression-lowering overlay cannot be resolved by the resolver, so they still need their own classification. Decide whether the remaining deduplication is worth it.
Activity
shunichironomura commentedon Oct 11, 2026
Warning
This content was written by an AI agent and must be verified by a human developer. After human verification, this alert may be removed.
Closing as not worth doing, after reviewing the attempt in #2037.
The resolver's role and the HIR classification are provably the same.
resolve_module_qualifiertakes the role fromalias_target.role()of the head alias. That is exactly whatmodule_alias_role(owner, head)returns, and HIR lowering already uses it. A qualified source path must start with a module alias in both places, so whenever the resolver succeeds the two answers agree. #2037's new HIR test passes onmainwithout the refactor.The duplication can't be removed, only moved. Overlay-bound instance members are invisible to the resolver, so the head-alias classification has to stay for them. Threading the role out of the resolver adds a second way to derive the boundary, chosen by whether the lookup succeeded. That gives the two a way to drift apart, which a single rule doesn't have. It also brings a new resolver API (
resolve_source_decl_path), aSourcePathBoundaryenum that is essentially the same asGraphRefBoundary, and a new module.The boundary belongs to the path as written, not to symbol resolution. It is decided by the path's first segment and the owner's alias scope. Deriving it from the path, through the typed
ModuleAliasName→ModuleAliasRolelookup, is the right layering. It isn't a string convention.If we later want a single owner for this rule, the better direction is one resolver-owned helper built on
module_alias_role. It would be called the same way for bound and unbound graph refs, and also byir/static_definitions.rs::resolve_unit, which classifies the head alias the same way.The test from #2037, covering import and include alias rules with and without overlay bindings, is worth keeping. It will land as its own test-only PR.
Generated by Claude Code