Rewrote 20 issue writeups to the extern/runtime-class vocabulary (#foreign→extern, foreign_class_map→runtime_class_map, parseForeignClassDecl→parseRuntimeClassDecl, findForeignMethodInChain→findRuntimeMethodInChain, dedupeForeignSymbol→ dedupeExternSymbol, is_foreign_c_api→is_extern_c_api, stale filename refs to the renamed examples, foreign-class→runtime-class, bare foreign→extern). Renamed issues/0043-…-foreign-class-…→…-runtime-class-…. PHASE 9 COMPLETE — 9.4 GATE PASSES: zero 'foreign' across src/library/examples/ issues/docs/editors/specs/readme/CLAUDE, excluding only the SQLite API constant SQLITE_CONSTRAINT_FOREIGNKEY + vendored sqlite3.c/.h (upstream third-party). Suite green (644 corpus / 443 unit, 0 failed).
3.4 KiB
0114 — namespace aliases leak transitively and collide first-wins, silently
RESOLVED (2026-06-11). Root cause:
lowerCall's namespace branch consulted the globalfn_ast_map["alias.fn"](registered first-wins byregisterQualifiedFn) with no per-importer gate, and fell back to the global LAST-wins bare map for comptime/generic members. Fix: the branch now routes plain-identifier alias roots through the carry-awarenamespaceAliasVerdict— visible targets dispatch the member fd pinned to the TARGET module (namespaceFnMember+ fd-keyedbareAuthorFuncId), ambiguous carries diagnose loudly, and an alias that exists only beyond one flat hop errors "namespace 'X' is not visible". Extern/builtin/ #compiler members keep the literal-symbol path. Regression tests:examples/0832-modules-namespace-alias-two-hop-not-visible.sx,examples/0833-modules-namespace-alias-carried-collision-ambiguous.sx,examples/0834-modules-namespace-alias-own-target-pin.sx.
Symptom. A namespace alias (t :: #import "target.sx";) declared in module
B is usable from ANY module whose import closure reaches B — at any depth, flat
or not — and when two modules register the same qualified name (t.helper),
the first registration silently wins (registerQualifiedFn:
if contains return). Expected (the approved carry design, session 72f): an
alias is visible one level deep — in the declaring module and in its DIRECT
flat importers — with own-wins / ambiguity-diagnostic collision semantics,
mirroring ordinary declarations.
This is the alias-side sibling of issue 0106 (bare-name over-permissiveness), plus a REJECTED-PATTERNS silent first-wins.
Reproduction
// target.sx
helper :: () -> i64 { 7 }
// facade.sx
t :: #import "target.sx";
// facade2.sx
#import "facade.sx";
// main.sx
#import "modules/std.sx";
#import "facade2.sx"; // TWO flat hops from the alias declaration
main :: () { print("{}\n", t.helper()); }
- Observed: prints
7— the alias rides two flat hops. - Expected:
't' is not visible(one-level carry;facade2.sxwould need to re-alias or flat-importfacade.sx's surface deliberately).
Collision face: two modules each declaring t :: #import of DIFFERENT
targets, both flat-imported by main — first-lowered wins silently.
Suspected area / fix shape
Qualified members are registered GLOBALLY (fn_ast_map["t.helper"],
registerQualifiedFn in src/ir/lower/decl.zig ~1912) with no per-importer
gate; lowerCall's namespace path (src/ir/lower/call.zig ~687) and the
comptime field-access path consult only that global map. Meanwhile
nominal.zig's qualifiedStructTemplate/qualifiedMemberMissing use STRICT
per-file namespace_edges — so carried aliases are inconsistently
over-visible for plain/comptime fns and under-visible for generic structs
(and alias.Type.method heads — see PLAN-STDLIB).
Fix shape: one carry-aware resolver on Lowering —
resolveNamespaceAlias(alias) → {own | carried(target) | ambiguous | none}
walking own namespace_edges[from] first, then the DIRECT
flat_import_graph[from] targets' edges (one level; ≥2 distinct targets →
diagnostic). Route every ns.member consumer through it: the global
qualified-name paths gain the gate, the strict nominal/type paths gain the
carry. See current/PLAN-STDLIB.md for the full design and the std.sx
restructure that depends on it.