zig
zig copied to clipboard
ziglang
use case: zig build on the command line without having to scroll up to find the compile errors
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.
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?
--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.
Something like grep's --after-context=num would be helpful. Then a limit could be set on the number of nodes after each error.
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
so as to not lose the command output, it would be nice if it was instead hidden behind --verbose-cmd or something similar.
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'
It is super annoying, all i want to see is the error message without having to scroll
EDIT:
i now remember i sent a PR about it years ago, nothing was done to improve it, wich is unfortunate and sad at the same time
The command doesn't change when you try to fix a bug in your code, so shadowing the error message only just to show a noisy command line is counter productive, wastes time
Asking people to type another noisy command as suggested above is putting the burden on the users to justify poor tool UX
"Just scroll", or "Buy a 2nd monitor", or "type a command that's not crossplatform" are not valid arguments to justify not having the option for a more useful output
Of if you still to not want to give users the option, at least reformat the output so the noisy command comes first, then the actual useful error message i am looking for
Ok looks like this https://github.com/ziglang/zig/pull/8513/ solves it
But the option is poorly named, it should be called something like: print_full_command_on_build_error
Also the description is poorly written: Output compile errors formatted for a human to read
It imply the compiler wasn't made for the user
--prominent-compile-errors is available from the CLI and build.zig for those wanting this use case
This was solved in #14647. Compile errors show up at the bottom now and they are also available via the protocol.