Skip to content

Conversation

@dasimmet
Copy link
Contributor

No description provided.

@malcolmstill
Copy link
Owner

Thanks for pulling this together @dasimmet! Looking good so far, but I have a question on the .always_tail change (which I will add to the particular line(s)).

@dasimmet
Copy link
Contributor Author

Ah yeah thanks for clarifying, I suppose we can also switch on the compiler backend instead of build mode, so debug builds with llvm can still use tail calls.
The fib example already segfaults in debug x86_64 i noticed.

The remaining errors in the test seems like a bug in zig's json parser in the 0.15.1 release...

The testsuite was failing with:

```
zig-aarch64-macos-0.15.1/lib/std/json/static.zig:572:44: error: type 'f64' cannot represent integer value '18446744073709551615'
                    if (f > std.math.maxInt(T)) return error.Overflow;
```

Interestingly in an example .wast (e.g. test-token's token.wast) the
line numbers are 4 and 8:

```
{"source_filename": "/Users/malcolm/.cache/zig/p/N-V-__8AAKtbtgBFkB_BMIKSUqC-temKvHmuqBSvjBlf4hD6/token.wast",
 "commands": [
  {"type": "assert_malformed", "line": 4, "filename": "token.0.wat", "text": "unknown operator", "module_type": "text"},
  {"type": "assert_malformed", "line": 8, "filename": "token.1.wat", "text": "unknown operator", "module_type": "text"}]}
```

which is hinting at maybe the json parser code running on
uninitialised data? Not sure.

Anyway, usize is way larger than we need anyway so dropping down to
u32 (say) is totally fine.
@malcolmstill
Copy link
Owner

malcolmstill commented Sep 28, 2025

Ah yeah thanks for clarifying, I suppose we can also switch on the compiler backend instead of build mode, so debug builds with llvm can still use tail calls. The fib example already segfaults in debug x86_64 i noticed.

The remaining errors in the test seems like a bug in zig's json parser in the 0.15.1 release...

I've fixed the json parser issue by reducing the width of the integer for the line field (see 189017d).

The testsuite still fails of course (but only on a few of the tests) because that will default to a debug build. Again we have options:

  1. Run the testsuite in CI with a --release build to get llvm
  2. Insist on llvm even in debug, e.g.
index e1c8e46..974992d 100644
--- i/build.zig
+++ w/build.zig
@@ -34,14 +34,15 @@ pub fn build(b: *Build) !void {
     const testrunner = b.addExecutable(.{
         .name = "testrunner",
         .root_module = b.addModule("testrunner", .{
             .root_source_file = b.path("test/testrunner/src/testrunner.zig"),
             .target = target,
             .optimize = optimize,
         }),
+        .use_llvm = true,
     });
     testrunner.root_module.addImport("zware", zware_module);
 
     const testsuite_dep = b.dependency("testsuite", .{});
 
     const testsuite_step = b.step("testsuite", "Run all the testsuite tests");
     for (test_names) |test_name| {

@malcolmstill malcolmstill changed the title DRAFT: zig 0.15.1 zig 0.15.1 Oct 6, 2025
@malcolmstill malcolmstill merged commit 207f932 into malcolmstill:master Oct 6, 2025
13 checks passed
@malcolmstill
Copy link
Owner

Thanks @dasimmet and @marler8997!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants