introduce a new tool for testing incremental compilation

[andrewrk]

This is a tiny component of an overall testing strategy. This provides the ability to have compact test cases that can be run with a single command which are then tested in isolation, aiding reproducibility. For example, I have included one test case along with this tool:

#target=x86_64-linux
#update=initial version
#file=main.zig
const std = @import("std");
pub fn main() !void {
    try std.io.getStdOut().writeAll("good morning\n");
}
#expect_stdout="good morning\n"
#update=change the string
#file=main.zig
const std = @import("std");
pub fn main() !void {
    try std.io.getStdOut().writeAll("おはようございます\n");
}
#expect_stdout="おはようございます\n"

You can run it like this:

$ stage3/bin/zig run ../tools/incr-check.zig -- stage4/bin/zig ../test/incremental/hello 
error: update 'change the string' failed:
thread 619922 panic: reached unreachable code
/home/andy/dev/zig/lib/std/debug.zig:404:14: 0x18c18ad in assert (zig)
    if (!ok) unreachable; // assertion failure
             ^
/home/andy/dev/zig/src/InternPool.zig:698:27: 0x1f94180 in view (zig)
                    assert(capacity > 0); // optimizes `MultiArrayList.Slice.items`
                          ^
/home/andy/dev/zig/src/Zcu/PerThread.zig:373:37: 0x1d3d9ea in updateZirRefs (zig)
        for (tracked_insts_list.view().items(.@"0"), 0..) |*tracked_inst, tracked_inst_unwrapped_index| {
                                    ^
/home/andy/dev/zig/src/Compilation.zig:3602:33: 0x1b0f249 in performAllTheWorkInner (zig)
            try pt.updateZirRefs();
                                ^
/home/andy/dev/zig/src/Compilation.zig:3496:36: 0x19d2b53 in performAllTheWork (zig)
    try comp.performAllTheWorkInner(main_progress_node);
                                   ^
/home/andy/dev/zig/src/Compilation.zig:2231:31: 0x19cf318 in update (zig)
    try comp.performAllTheWork(main_progress_node);
                              ^
/home/andy/dev/zig/src/main.zig:4104:32: 0x1a13cf3 in serve (zig)
                try comp.update(main_progress_node);
                               ^
/home/andy/dev/zig/src/main.zig:3399:22: 0x1a316c6 in buildOutputType (zig)
            try serve(
                     ^
/home/andy/dev/zig/src/main.zig:263:31: 0x18c387a in mainArgs (zig)
        return buildOutputType(gpa, arena, args, .{ .build = .Exe });
                              ^
/home/andy/dev/zig/src/main.zig:209:20: 0x18bf9fa in main (zig)
    return mainArgs(gpa, arena, args);
                   ^
/home/andy/dev/zig/lib/std/start.zig:532:37: 0x18bf0f5 in posixCallMainAndExit (zig)
            const result = root.main() catch |err| {
                                    ^
/home/andy/dev/zig/lib/std/start.zig:277:5: 0x18bec11 in _start (zig)
    asm volatile (switch (native_arch) {
    ^
???:?:?: 0xc in ??? (???)
Unwind information for `???:0xc` was not available, trace may be incomplete

You can see how once this patchset is merged, this will become our first incremental compilation bug report, and it comes with a reduction.

A future enhancement will provide the ability to generate these test cases using fuzzer input and test various properties, such as path independence.

[sno2]

I don't understand this move. Wouldn't this be better on std.log itself? That is what Go does if that counts for anything https://pkg.go.dev/log#Fatal

[mlugg]

What another language does is entirely irrelevant, especially one as different as Go. Why would this live in std.log? Just because it happens to use that API doesn't mean it's part of it. std.process seems like an entirely reasonable place for this to live given its other task of terminating the process with exit code 1.

[sno2]

Go and Zig both allow creating custom loggers. This is important because I would like to be able to call fatal on my custom logger without duplicating this function.

[nektro]

if std.log.fatal was going to exist, i would still expect this one to exist and for std.log.fatal to call it

[andrewrk]

I think it belongs in process since it exits the process.

[andrewrk]

failing incremental test case filed as #20697