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

16
issues/0092-raw-reserved-value-numeric-limit-shadow.md
View File

@@ -17,13 +17,13 @@
> guard so inferred types match lowering (avoids the issue-0083 two-resolver
> desync).
>
> Bare `f64.epsilon` / `s32.max` (no shadowing binding) still fold — the parser
> Bare `f64.epsilon` / `i32.max` (no shadowing binding) still fold — the parser
> classifies a bare builtin name as a `.type_expr` (parser.zig:2743), so the
> bare receiver is never value-shadowed even in a scope where `` `f64 `` is
> bound. Float-only-on-int and non-numeric-receiver errors are unchanged.
>
> Regression: `examples/0161-types-numeric-limit-value-shadow.sx` (raw
> `` `f64 ``/`` `s32 ``/`` `u8 `` value reads coexisting with bare folds) +
> `` `f64 ``/`` `i32 ``/`` `u8 `` value reads coexisting with bare folds) +
> unit test in `src/ir/expr_typer.test.zig`. NL.1 (`examples/0148`) / NL.2
> (`examples/0159`, `examples/0160`) unregressed.
@@ -33,7 +33,7 @@
Field access on a raw reserved-spelled value binding is interpreted as a builtin
type numeric-limit access instead of an ordinary value field access. Observed:
the repro prints `0.000000 2147483647` (`f64.epsilon` / `s32.max`). Expected:
the repro prints `0.000000 2147483647` (`f64.epsilon` / `i32.max`). Expected:
it prints `12 78` from the `Box` fields.
## Reproduction
@@ -41,12 +41,12 @@ it prints `12 78` from the `Box` fields.
```sx
#import "modules/std.sx";
Box :: struct { epsilon: s64; max: s64; }
Box :: struct { epsilon: i64; max: i64; }
main :: () -> s32 {
main :: () -> i32 {
`f64 := Box.{ epsilon = 12, max = 34 };
`s32 := Box.{ epsilon = 56, max = 78 };
print("{} {}\n", `f64.epsilon, `s32.max);
`i32 := Box.{ epsilon = 56, max = 78 };
print("{} {}\n", `f64.epsilon, `i32.max);
return 0;
}
```
@@ -68,7 +68,7 @@ intercept for actual type receivers (`.type_expr`, and bare reserved integer
names with no value binding). If raw provenance is available in the AST, using it
to disambiguate is also acceptable, but the observable rule must be that
`` `f64.epsilon `` reads the value field when `` `f64 `` is a value binding,
while bare `f64.epsilon` / `s32.max` still fold as numeric limits.
while bare `f64.epsilon` / `i32.max` still fold as numeric limits.
Verification: pin a regression test from the repro above. It should print
`12 78`. Also verify the existing numeric-limit examples still pass: