Commit Graph

6 Commits

Author SHA1 Message Date
Matthew Lugg 5492b1e326 tests: move incremental target matrix out of manifests
Having the matrix of test targets for incremental compilation in the
individual test manifests has turned out to be inconvenient for a few
reasons: the tests are almost certain to accidentally get out of sync,
disabling targets entirely is annoying to do, and incr-check needs to
take care to print the target in all error messages (which currently
does not always happen).

If I recall correctly, I originally designed it this way because it
allows targets to be disabled at the granularity of individual tests,
but there's an easier approach to that: just let a test manifest that it
should be *skipped* on a certain target! As skipping is the rare case,
and also the case you want readers to notice, it makes sense for *it* to
be explicitly specified, like how unit tests use `error.SkipZigTest`.

So, `incr-check` no longer runs through a list of targets specified in
the manifest. Instead, it accepts (and, in fact, requires) a single
target on the command line, and runs the test for that specific target.
If the file contains a `#skip_target` directive for that target, then
`incr-check` exits immediately, so we can still disable targets at
individual test granularity, but you can also disable a target for all
tests by just commenting it out of the matrix in `test/tests.zig`.

As a nice bonus, this also allows the build system to run different
incremental test targets in parallel, because the targets are now
different steps.

This definitely seems like a better way to split the work between the
build system and incr-check---sorry for getting this wrong initially!
2026-04-16 12:37:08 +02:00
Alex Rønne Petersen 13839127b9 test: disable incremental tests on wasm32-wasi-selfhosted
https://codeberg.org/ziglang/zig/issues/31810
2026-04-11 04:40:16 +02:00
Alex Rønne Petersen a38c6bbcc4 test: disable incremental tests on x86_64-windows-selfhosted
https://codeberg.org/ziglang/zig/issues/31773
2026-04-06 23:04:14 +02:00
Pavel Verigo ad7a028228 stage2-wasm: pass incremental tests
This PR enables all incremental tests under the `test/incremental` directory, except one: `change_exports`, which is currently ignored as it requires a non-trivial amount of work on the linker, since we do not currently support exporting data symbols.

To enable the other tests, the following fixes were needed:

1. `src/link/Wasm.zig`: instead of chasing function type through Nav, get it directly.
2. `src/target.zig`: `.panic_fn` appears to work fine with the wasm backend.
3. `src/codegen/wasm/CodeGen.zig`: there was a liveness related bug that caused some `ArenaAllocator` code to crash the backend.

More info on (3), the liveness and local reuse code in the backend for years in unfinished state. For example there is currently no branch merging and reuse happens only when inst die in same block level. I initially considered doing a large refactor to implement everything correctly, but aborted due to its sheer size and currently! no clear idea about how to do this efficiently.

Instead, I fixed the bug with minimal changes and removed useless code, keeping the old solution otherwise intact.
2026-04-04 15:21:35 +02:00
Matthew Lugg 4a494a8cf9 tests: enable incremental tests for x86_64-linux-llvm
These all pass now! I have also removed the warning about the LLVM
backend not supporting incremental compilation; I expect it will work
sort of okay in practice by now.
2026-03-28 16:50:43 +00:00
Matthew Lugg 0978566db8 incremental: handle loss of main struct instruction
My changes to how incremental compilation handles container types mean
that, at least for now, it is possible for the ZIR `.main_struct_inst`
of a source file to be lost (this happens if the number of top-level
fields in a file changes for instance). I missed a few things which
needed changing to account for this, which could lead to crashes with
certain (trivial) changes---oops!

Adds two new incremental test cases. They are currently disabled for
wasm32-wasi-selfhosted because they both trigger a crash in the WASM
backend.
2026-03-12 21:27:16 +01:00