Support importing modules (module alias imports)

[stephanemagnenat]

Problem

Currently, use only supports importing symbols from modules (and * globs). It is not possible to import a module itself and then refer to it as a namespace.

Example that does not work today:

use deep::deeper;

deeper::symbol

At the moment, UseTree::Name(path) is always interpreted as “import the last segment as a symbol from its parent module”, so use deep::deeper is treated as a symbol import instead of a module alias.

Goal

Support module alias imports, similar to Rust:

use deep::deeper;       // introduces local name `deeper`
use deep::deeper::mod1; // introduces local name `mod1`

So that qualified paths starting with the alias are resolved correctly.

Proposed minimal approach

1. Extend Use (in uses.rs)
   • Add a new variant, e.g.:

     Use::Module { alias: Ustr, target: Path, span: Location }
     

   • alias is the locally introduced name.
   • target is the full module path.
2. Resolve module imports in import_resolver.rs
   • When flattening UseTree::Name(path):
     • If the full path refers to a module → create Use::Module.
     • Otherwise, fall back to existing symbol-import logic.
   • This requires extending ModulesResolver with:

     fn module_exists(&self, module: &Path) -> bool;
     

3. Path resolution changes
   • When resolving a qualified path like x::y::z:
     • If x is a module alias imported via Use::Module, rewrite the path to <alias-target>::y::z.
     • Then continue with normal resolution.
   • This likely lives in ModuleEnv or wherever multi-segment paths are resolved.
4. Conflict handling
   • Module alias imports introduce a local name and should:
     • conflict with local definitions of the same name
     • conflict with other imports (symbol or module) introducing the same name
     • participate in existing duplicate-import detection

Non-goals (for now)

• No reexports (pub use-style behavior)
• No as renaming (can be added later)
• No assumption that partial paths are modules unless they actually exist in the module table

Status

• Import resolution infrastructure (import_resolver, conflict detection, glob handling) is in place.
• Unit tests exist for symbol imports and glob conflicts.
• Module alias imports are intentionally deferred to keep the current change minimal.