fix(diag): imported generic struct field with bad type → diagnostic, not .unresolved/silent stub [stdlib E3 attempt-4]

attempt-3 closed the MAIN-file value-param-as-type quadrant (0172) in the
UnknownTypeChecker, but the checker only walks main-file decls — an IMPORTED
generic struct's field with a bad type name was never checked. Worse, the
generic-struct INSTANTIATION resolved its field type nodes in the (possibly
cross-module) instantiation site's source context, not the template's module.
So for `Bad :: struct($N: u32) { x: N; }` declared in an imported module and
used as `Bad(3)` from main, the field `x: N` resolved against the main file:
the value-param-as-type leaf poisoned it with `.unresolved` and PANICKED at
LLVM emission, and the genuinely-undeclared sibling (`y: Missing` in a generic
import, distinct from the non-generic 0759 case) silently fabricated a 0-field
stub.

Root cause + uniform fix: capture the declaring module on each StructTemplate
and resolve its field type nodes in THAT source context during
instantiateGenericStruct. The source-aware nominal leaf then classifies main vs
imported by the TEMPLATE's file, so both failure modes are diagnosed at the
right authority for every quadrant — main + imported, undeclared name + value
param used as a type:
- imported `.undeclared` field → the existing leaf emits "unknown type 'X'"
  (now reached because `from` is the template's module, not main).
- imported value-param-as-type → the `is_generic` leaf, when the name is bound
  as a comptime VALUE (`comptime_value_bindings`), emits the tailored
  "'N' is a value parameter, not a type" hint (gated to non-main; the
  UnknownTypeChecker owns the main-file case). Caught in every type position
  (`x: N`, `*N`, `[3]N`, `?N`). A genuinely-unbound type param (`$R`) stays a
  silent `.unresolved`.

No `.unresolved` reaches LLVM for these cases (hasErrors halts after lowering);
the emit_llvm `.unresolved` @panic tripwire stays as the last-resort sentinel.
Valid value-param VALUE positions (`[N]u8` dim, `Vector(N,T)` lane) and
`$T:Type`/`$T:Protocol` type-param fields still resolve.

Regressions:
- 0760-modules-imported-generic-value-param-as-field-type (panic-before / clean
  diagnostic-after).
- 0761-modules-imported-generic-undeclared-field (silent-compile-before / clean
  diagnostic-after).
0171/0172/0759 stay green; main-file quadrants emit exactly one error.

Gate: zig build; zig build test (423/423 + LSP corpus sweep); run_examples 501
passed / 0 failed (prior 499 byte-identical); m3te ios-sim build exit 0.
This commit is contained in:
agra
2026-06-08 09:37:52 +03:00
parent a0390a63ab
commit 81621703ca
12 changed files with 130 additions and 7 deletions

View File

@@ -0,0 +1,18 @@
// A generic struct's VALUE param (`$N: u32`) named in a TYPE position must emit
// a clean diagnostic even when the struct is declared in an IMPORTED module —
// not just the main file (examples/0172 covers the main-file case). Before the
// fix the imported template's field `x: N` resolved to the `.unresolved`
// sentinel and PANICKED at LLVM emission ("unresolved type reached LLVM
// emission"); the field type leaf now diagnoses the imported value-param misuse
// at the reference, the same way the main-file `UnknownTypeChecker` does.
//
// Expected: `error: 'N' is a value parameter, not a type` pointing into lib.sx;
// exit 1. Regression (stdlib E3).
#import "modules/std.sx";
#import "0760-modules-imported-generic-value-param-as-field-type/lib.sx";
main :: () -> s32 {
b : Bad(3) = .{ x = 1 };
print("{}\n", b.x);
return 0;
}

View File

@@ -0,0 +1,10 @@
// Flat-imported generic struct whose VALUE param `$N: u32` is named in a TYPE
// position (`x: N`). Because this module is imported (not the main file), the
// `UnknownTypeChecker` trusts it and never walks it — so the field type leaf is
// the sole guard. `instantiateGenericStruct` resolves the template's field nodes
// in THIS source context, so the leaf classifies the value-param misuse as
// imported and emits the tailored hint instead of poisoning the field with the
// `.unresolved` sentinel (which panicked at LLVM emission before the fix).
Bad :: struct($N: u32) {
x: N;
}

View File

@@ -0,0 +1,19 @@
// A genuinely-undeclared type in an IMPORTED GENERIC struct field must emit
// "unknown type" even when the struct is instantiated from the main file —
// 0759 only covered a non-generic imported struct instantiated in-module.
// Before the fix the generic template's fields resolved in the main-file
// instantiation context, so the leaf trusted them as main-file decls and
// silently stubbed `Missing` (the program compiled and printed `b.x`). The
// template's fields now resolve in the template's own source context, so the
// undeclared name surfaces.
//
// Expected: `error: unknown type 'Missing'` pointing into lib.sx; exit 1.
// Regression (stdlib E3).
#import "modules/std.sx";
#import "0761-modules-imported-generic-undeclared-field/lib.sx";
main :: () -> s32 {
b : Bad(s32) = .{ x = 1, y = 2 };
print("{}\n", b.x);
return 0;
}

View File

@@ -0,0 +1,12 @@
// Flat-imported generic struct with a genuinely-undeclared field type
// (`y: Missing`). 0759 covers a NON-generic imported struct; a generic one is
// instantiated cross-module, so before the fix its field nodes were resolved in
// the (main-file) instantiation context — the source-aware leaf saw "main",
// trusted it to the `UnknownTypeChecker` (which never walks imports), and
// silently fabricated a 0-field stub. `instantiateGenericStruct` now resolves
// the template's fields in THIS module's source context, so the undeclared name
// surfaces at the reference.
Bad :: struct($T: Type) {
x: T;
y: Missing;
}

View File

@@ -0,0 +1,5 @@
error: 'N' is a value parameter, not a type; introduce a generic type parameter with `$N: Type`
--> examples/0760-modules-imported-generic-value-param-as-field-type/lib.sx:9:8
|
9 | x: N;
| ^

View File

@@ -0,0 +1,5 @@
error: unknown type 'Missing'
--> examples/0761-modules-imported-generic-undeclared-field/lib.sx:11:8
|
11 | y: Missing;
| ^^^^^^^