The 0100 identity fix registers a namespaced import's own functions under a module-qualified name (ns.fn) in fn_ast_map WITHOUT an eager declareFunction, so the alias is lowered through lazyLowerFunction's null-FuncId lowerFunction path. That path had no Function.source_file to restore (the non-null path does setCurrentSourceFile(func.source_file)), so the alias lowered in the CALLER's visibility context. A qualified function that called a helper from its OWN module's flat import was then rejected "not visible". Fix: - ProgramIndex.qualified_fn_source maps each ns.fn alias to its declaring source file, populated in registerQualifiedFn (current_source_file is pinned to the decl's source by registerNamespaceQualifiedFns). - lazyLowerFunction's null-FuncId branch restores that source before lowerFunction, so ns.fn's body lowers in its own module's context and its intra-module / own-import callees resolve. - lowerFunction records Function.source_file = current_source_file on the freshly-begun function (matching declareFunction), so the lowered alias carries its own module for diagnostics/emit. Regression: examples/0720-modules-qualified-own-import.sx — calc.compute (a qualified alias) calls triple/base from calc.sx's own flat import; reports "'triple' is not visible" on the attempt-1 code, passes after. 0719's cross-module dual-parse assertion stays green. issues/0100 RESOLVED banner extended with the F1 follow-up.
9 lines
392 B
Plaintext
9 lines
392 B
Plaintext
// `calc` is pulled in under a QUALIFIED namespace by the consumer
|
|
// (`calc :: #import …`), yet its own body calls `triple` / `base` from
|
|
// calc.sx's OWN flat `#import "util.sx"`. The qualified alias `calc.compute`
|
|
// must lower in calc.sx's source context so those own-import callees stay
|
|
// visible — issue 0100 F1.
|
|
#import "util.sx";
|
|
|
|
compute :: () -> s64 { return triple(base()); }
|