use case: zig build on the command line without having to scroll up to find the compile errors

[andrewrk]

It's not apparent yet because some of this stuff is not yet implemented but there are multiple consumers of the zig build system. The programmer using a terminal is the main use case for now, but there is also IDEs, language servers, package manager, as well as other terminal based usages such as troubleshooting the build, visualizing it, and the --help menu.

Sometimes a zig build invocation can end up printing long error traces with "command failed" being printed after compile errors, forcing the user to have to scroll up. This is not an ideal experience. It is important for this troubleshooting information to be printed by default, however, it should be possible to get into a workflow where only the thing you care about is printed, which is often compile errors.

It's not super simple to solve this because compile errors could come from multiple different invocations of the zig compiler, or even from compiling C or C++ code. Furthermore, compile error messages from zig contain extra metadata that can't be communicated in the terminal. For example they are actually in a tree form, with error notes being attached to parent errors. Zig also has no error limit of how many to print, because the idea is that they would be collected by some kind of IDE and displayed inline with source code, in addition to a global list.

However, the use case of not using an IDE is also valid and so this issue is open to track progress on that front. I don't think --quiet adequately captures the intent here, which is to specifically focus compile errors - not to silence all output. It's possible we will see --watch turn into something that addresses this use case.

I also don't think reversing the traceback is appropriate. Status quo is the natural stack order; nothing needs to be buffered, and the beginning and ends of stack traces connect correctly to the error messages on either end - including with error return traces. Buffering and reversing the traceback is not a sufficient solution as well as introduces new drawbacks.

This issue is not yet a concrete proposal because I'd like to focus on the zig build system and the package manager (#943) together, but my main focus right now is the self-hosted compiler (#89). Suffice to say, this use case will be solved in a satisfying way eventually, but it's unclear exactly how yet. This is something I expect to be addressed in the 0.9.0 release cycle.

[pjz]

Maybe have the default output be human readable but allow a --json flag that would dump the full set of errors in a json structure to make it more easily consumed by IDEs and other tools? or --xml if you're feeling that 90s vibe :) or both, or some other format even, if it helps compatibility. Or if you want the full trace to be the default, add a --human or --short that summarizes nicely for people to read?

[ikskuh]

I strongly support more JSON compiler output

[pfgithub]

--color=on 2>&1 | less works well for now, but you can't go back to it if you want to view the output later.

[frmdstryr]

Something like grep's --after-context=num would be helpful. Then a limit could be set on the number of nodes after each error.

[frmdstryr]

Bump... just had an error trace that was 1795 lines long lol

[ikskuh]

Bump as well, STN-Ratio of 0,003:
One error (3 lines), 1027 lines of output. Problem here: My terminal only has 1000 lines of backlog, so i actually needed to grep for my error to be able to see it.
Having a mode that removes all note: would help already

[nektro]

so as to not lose the command output, it would be nice if it was instead hidden behind --verbose-cmd or something similar.

[g-w1]

#6670 This was already rejected here.

[pfgithub]

A simple thing that could be done to improve this is to only show the source code for the first error and not the rest of the trace

thread 524311 panic: error
./source.zig:2:5: 0x22d221 in main (test)
    @panic("error");
/std/start.zig:345:37: 0x204cfe in std.start.posixCallMainAndExit (test)
/std/start.zig:163:5: 0x204ba2 in std.start._start (test)

This would make it harder to find errors when they show up in the wrong place though, like with print functions

/std/fmt.zig:367:9: error: Unused arguments
        @compileError("Unused arguments");
        ^
/std/io/writer.zig:33:34: note: called from here
/std/log.zig:147:35: note: called from here
/std/log.zig:222:16: note: called from here
./test.zig:2:28: note: called from here
    @import("std").log.info("Hi!", .{25});   // you want to see this line, but it would get hidden
                           ^
./test.zig:1:21: note: called from here
/std/io/writer.zig:33:34: note: error set '@typeInfo(@typeInfo(@TypeOf(std.fmt.format)).Fn.return_type.?).ErrorUnion.error_set' cannot cast into error set 'std.os.WriteError'