lab/sx
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

lang: rename signed integer types sN -> iN

Browse Source 
Surface rename of the signed integer family: s1..s64 become i1..i64
(u1..u64, usize, isize unchanged). 'string' keeps the s-prefix arm in
name classification; width parsing moves to the i-prefix arm next to
isize.

Internal TypeId tags follow the surface (.s8/.s16/.s32/.s64 ->
.i8/.i16/.i32/.i64), as do mono-key mangle fragments (ptr_i64,
tu_i64_bool) and all display/diagnostic formatting (i{d}).

Migrated in the same sweep: stdlib + examples + issue repros + FFI C
companions (shared symbol names like ffi_id_i64), expected
stdout/stderr/ir snapshots, specs.md, readme.md, CLAUDE.md/AGENTS.md,
implementation_plan.md, docs/, issue writeups. Vendored stb_image and
historical flow state left untouched.

zig build test: 426/426; examples suite: 595/595.
This commit is contained in:
agra
2026-06-12 09:31:53 +03:00
parent 515ecebea7
commit d8076b9333
1054 changed files with 6836 additions and 6839 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
issues/0097-enum-value-failable-error-slot-corruption.md
View File

@@ -18,7 +18,7 @@ value resolves against `failableSuccessType(ret_ty)` (the value type / value-tup
literal gets its real ordinal and the success-return path appends the `0` error slot; an
**explicit full failable tuple** literal (`return (v..., e)`, arity == full-tuple field count)
keeps the full-tuple target so its trailing error element resolves against the error set and is
forwarded as-is. The s32 case was already correct because integer literals don't resolve variants
forwarded as-is. The i32 case was already correct because integer literals don't resolve variants
against `target_type`.
Two follow-up defects from the first cut of this fix were corrected (attempt-2 review):
@@ -50,7 +50,7 @@ Below preserved as a record of the original problem.
A value-failable function `-> (EnumType, !ErrSet)` writes a **garbage nonzero tag into the error
slot on the SUCCESS path**. Per specs.md the error channel must be `0` on success ("0 in the
error slot means no error"). Every **runtime read** of the slot on success (`cast(s64) err`, bare
error slot means no error"). Every **runtime read** of the slot on success (`cast(i64) err`, bare
`if err`, `err == error.X`, and therefore `error_tag_name(err)`) reports a false error. Only the
path-sensitive compile-time proof `if !err` reads correctly (it is tied to the SSA value, not a
runtime load of the slot), which is why it masks the bug.
@@ -71,12 +71,12 @@ pick :: (s: string) -> (Color, !E) {
raise error.Nope;
}
main :: () -> s32 {
main :: () -> i32 {
c, e := pick("red"); // SUCCESS -> error slot MUST be 0
print("error e (int) = {}\n", cast(s64) e); // EXPECT 0 ; BUG prints 1
print("error e (int) = {}\n", cast(i64) e); // EXPECT 0 ; BUG prints 1
if e { print("bare-if e: ERROR (WRONG)\n"); } else { print("bare-if e: ok\n"); }
if e == error.Nope { print("e == Nope (WRONG)\n"); } else { print("e != Nope (ok)\n"); }
if !e { print("guard !e: value c (int) = {}\n", cast(s64) c); } // c = 0 = .red (CORRECT)
if !e { print("guard !e: value c (int) = {}\n", cast(i64) c); } // c = 0 = .red (CORRECT)
return 0;
}
```
@@ -96,14 +96,14 @@ e != Nope (ok)
guard !e: value c (int) = 0
```
## Contrast — the IDENTICAL shape with an s32 value is CORRECT
## Contrast — the IDENTICAL shape with an i32 value is CORRECT
```sx
pick :: (n: s32) -> (s32, !E) { if n > 0 { return n; } raise error.Nope; }
pick :: (n: i32) -> (i32, !E) { if n > 0 { return n; } raise error.Nope; }
// v, e := pick(5); → error slot = 0 (correct); bare-if e: ok
```
The split is **enum-value-specific** because only an enum literal (`return .variant`) resolves its
tag against `target_type`. An integer literal does not, so the s32 path never got mis-stamped with
tag against `target_type`. An integer literal does not, so the i32 path never got mis-stamped with
the failable-tuple type and never took the false forwarding branch.
## Root cause (confirmed at ground truth)
@@ -115,6 +115,6 @@ failable tuple). The LLVM IR on the success path was:
ret { i64, i32 } { i64 0, i32 undef } ; error slot UNDEF, not 0 (.blue gave i64 0 too — value lost)
```
vs. the s32 case which already produced `ret { i32, i32 } { i32 7, i32 0 }`. After narrowing the
vs. the i32 case which already produced `ret { i32, i32 } { i32 7, i32 0 }`. After narrowing the
return target to the value type, the enum success path produces `ret { i64, i32 } zeroinitializer`
(value 0 = `.red`, error slot 0), and `.blue` correctly carries ordinal 2.