9274d47adf
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.
2 lines
25 B
Plaintext
2 lines
25 B
Plaintext
qualified-own-import: ok
|