From 1c143834957db308705f5aa8456e3f6a7e00941b Mon Sep 17 00:00:00 2001 From: agra Date: Mon, 1 Jun 2026 22:35:02 +0300 Subject: [PATCH] ERR/E5.1: verify generic failable composition (sub-feature 8); resolve 0062, file 0064 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Generic value-carrying failable composition works with the documented $T: Type generic form (catch / destructure / failure-propagation / a second monomorphization at a different T). Issue 0062 was an invalid-repro report — it used the non-generic T: type form, which is a plain Type-valued param, not a generic type parameter. Marked 0062 resolved (not a bug). The only real residual: a non-$ T: Type function param used as a type silently resolves to an empty {} (renders T{}) instead of erroring. Filed as 0064 (deferred, orthogonal to ERR — the $T idiom works). Regression: 1044-errors-generic-failable-composition.sx. --- ...044-errors-generic-failable-composition.sx | 29 ++++++++++++ ...4-errors-generic-failable-composition.exit | 1 + ...errors-generic-failable-composition.stderr | 1 + ...errors-generic-failable-composition.stdout | 4 ++ ...neric-failable-return-not-monomorphized.md | 18 ++++++++ ...ondollar-type-param-silent-empty-struct.md | 46 +++++++++++++++++++ 6 files changed, 99 insertions(+) create mode 100644 examples/1044-errors-generic-failable-composition.sx create mode 100644 examples/expected/1044-errors-generic-failable-composition.exit create mode 100644 examples/expected/1044-errors-generic-failable-composition.stderr create mode 100644 examples/expected/1044-errors-generic-failable-composition.stdout create mode 100644 issues/0064-nondollar-type-param-silent-empty-struct.md diff --git a/examples/1044-errors-generic-failable-composition.sx b/examples/1044-errors-generic-failable-composition.sx new file mode 100644 index 0000000..a107a4e --- /dev/null +++ b/examples/1044-errors-generic-failable-composition.sx @@ -0,0 +1,29 @@ +// Generic function with a value-carrying `!` return composes (ERR E5.1 +// sub-feature 8). A `$T: Type` generic whose return is `(T, !E)` monomorphizes +// per call: `return try f()` propagates the closure's error, and each +// monomorphization's success value flows through as the concrete `T`. +// (Regression: confirms issue 0062 was an invalid-syntax repro — the bug only +// appeared with the non-generic `T: Type` form; the `$T` form works.) + +#import "modules/std.sx"; + +E :: error { Bad } + +wrap :: ($T: Type, f: Closure() -> (T, !E)) -> (T, !E) { return try f(); } + +main :: () -> s32 { + // success, consumed by catch + print("catch={}\n", wrap(s32, closure(() -> (s32, !E) { return 7; })) catch e -1); // 7 + + // success, consumed by destructure (binds value + error slot) + r, err := wrap(s32, closure(() -> (s32, !E) { return 9; })); + no_err := if err == error.Bad then false else true; + print("destr={} ok={}\n", r, no_err); // destr=9 ok=true + + // failure path: the raised tag propagates through the generic `try` + print("fail={}\n", wrap(s32, closure(() -> (s32, !E) { raise error.Bad; }) ) catch e -1); // -1 + + // a second monomorphization at a different T + print("u8={}\n", wrap(u8, closure(() -> (u8, !E) { return 200; })) catch e 0); // 200 + return 0; +} diff --git a/examples/expected/1044-errors-generic-failable-composition.exit b/examples/expected/1044-errors-generic-failable-composition.exit new file mode 100644 index 0000000..573541a --- /dev/null +++ b/examples/expected/1044-errors-generic-failable-composition.exit @@ -0,0 +1 @@ +0 diff --git a/examples/expected/1044-errors-generic-failable-composition.stderr b/examples/expected/1044-errors-generic-failable-composition.stderr new file mode 100644 index 0000000..8b13789 --- /dev/null +++ b/examples/expected/1044-errors-generic-failable-composition.stderr @@ -0,0 +1 @@ + diff --git a/examples/expected/1044-errors-generic-failable-composition.stdout b/examples/expected/1044-errors-generic-failable-composition.stdout new file mode 100644 index 0000000..43262cc --- /dev/null +++ b/examples/expected/1044-errors-generic-failable-composition.stdout @@ -0,0 +1,4 @@ +catch=7 +destr=9 ok=true +fail=-1 +u8=200 diff --git a/issues/0062-generic-failable-return-not-monomorphized.md b/issues/0062-generic-failable-return-not-monomorphized.md index 6cc4fe3..5ebb11c 100644 --- a/issues/0062-generic-failable-return-not-monomorphized.md +++ b/issues/0062-generic-failable-return-not-monomorphized.md @@ -1,5 +1,23 @@ # 0062 — generic function with a value-carrying `!` return miscompiles +> **✅ RESOLVED (2026-06-01) — NOT A BUG (invalid repro syntax).** The repro used +> the non-generic form `(T: type, …)` / `(T: Type, …)` — a plain value param of +> type `Type`, NOT a generic type parameter. Per `specs.md` (the `$` sigil +> introduces a generic type parameter), a function generic type param must be +> `$T: Type`. With the correct form, generic value-carrying failable composition +> (ERR E5.1 sub-feature 8) works fully: +> +> ```sx +> wrap :: ($T: Type, f: Closure() -> (T, !E)) -> (T, !E) { return try f(); } +> wrap(s32, closure(() -> (s32, !E) { return 7; })) catch e -1 // 7 +> r, err := wrap(s32, closure(() -> (s32, !E) { return 9; })) // r=9 +> wrap(s32, closure(() -> (s32, !E) { raise error.Bad; })) catch e -1 // -1 +> ``` +> +> The only real (separate, orthogonal) defect found: a NON-`$` `T: Type` function +> param used as a type silently resolves to an empty `{}` (renders `T{}`) instead +> of erroring — tracked as **issue 0064**, deferred (not ERR-scoped). + ## Symptom A generic function whose return type is a value-carrying failable in the generic diff --git a/issues/0064-nondollar-type-param-silent-empty-struct.md b/issues/0064-nondollar-type-param-silent-empty-struct.md new file mode 100644 index 0000000..ab736ce --- /dev/null +++ b/issues/0064-nondollar-type-param-silent-empty-struct.md @@ -0,0 +1,46 @@ +# 0064 — non-`$` `T: Type` function param used as a type silently yields `{}` + +## Symptom + +A function parameter declared `T: Type` (or lowercase `T: type`) — i.e. WITHOUT +the `$` generic-type-parameter sigil — that is then referenced in a type position +(`-> T`, `Closure() -> T`, etc.) silently resolves `T` to a fabricated empty +struct `{}` instead of the caller's argument type. The function "runs" but +produces garbage (the value renders as `T{}`), with no diagnostic. + +```sx +idwrap :: (T: Type, f: Closure() -> T) -> T { return f(); } +main :: () -> s32 { + print("{}\n", idwrap(s32, closure(() -> s32 { return 7; }))); // prints "T{}", want 7 + return 0; +} +``` + +The correct, working form is the generic `$T: Type` (the `$` introduces the +generic type parameter — see `specs.md` §"`$` generic type parameter +introduction"). With `$T`, the binding is established and the result is `7`. + +So this is not a miscompile of a valid program — it's a **missing diagnostic** +for a misuse: a non-generic `Type`-typed value param can't be used as a type, and +should be rejected (or the `$` requirement explained), not silently turned into +an empty struct. + +## Reproduction + +See above. Compare `idwrap :: ($T: Type, …)` (works, prints 7) vs `idwrap :: (T: +Type, …)` (prints `T{}`). + +## Investigation prompt + +In [src/ir/lower.zig](../src/ir/lower.zig), `resolveTypeWithBindings` resolves a +`.type_expr` named `T` by checking `type_bindings` (works for `$T`, which +`buildTypeBindings` registers). For a non-`$` `T: Type` param there is no binding, +so resolution falls through to `type_bridge.resolveAstType`, which fabricates an +empty-struct stub for the unknown name `T` — the classic "silent empty struct" +the CLAUDE.md REJECTED-PATTERNS warn about. Fix options: (1) at scan/sema time, +reject referencing a non-`$` `Type`-typed param in a type position with a +diagnostic ("type parameter must be introduced with `$` — write `$T: Type`"); or +(2) make `resolveAstType` return `.unresolved` + a diagnostic for an unknown bare +type name in a generic-eligible position, instead of stubbing `{}`. Deferred — +orthogonal to ERR; the working `$T` idiom exists. Low priority but should not stay +silent.