b9cfe2554f
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).
1.3 KiB
0019 — #import is non-transitive (C-function scope across files)
Status: superseded — kept for reference. Relocated from the old
examples/issue-0019/fixture during the test-layout migration. The behavior it probed (A imports B and C; C must NOT see B'sexternC functions just because A imported B) is now covered by the passing testexamples/0706-modules-import-non-transitive.sx.
What it probed
main imports both c_wrapper.sx (which declares C extern functions) and
other.sx. other.sx should not gain access to c_wrapper's C functions
transitively — using one should produce the "not visible; #import the module that
declares it" diagnostic.
main_good.sx— the valid arrangement.main_bad.sx— the arrangement that must be rejected.c_wrapper.sx,other.sx— the imported modules.
Caveat (why it doesn't run as-is)
The fixture uses relative imports (#import "../modules/std.sx"), which only
resolve relative to a specific working directory and violate the project's
"always package:/module-path imports, never relative" rule. It is not runnable
from the repo root and is not wired into the suite. If revived, rewrite the
imports to the standard modules/... form and pin expected output; otherwise it
can be deleted (the scenario is already covered by 0706-modules-import-non-transitive).