"zig run" pollutes debug output with unexpected messages "LLVM Emit Object... LLVM Emit Object... MachO Flush..."

[obask]

Zig Version

0.12.0-dev.3644+05d975576

Steps to Reproduce and Observed Behavior

invoke "zig run" on any source file

Expected Behavior

According to "No hidden control flow" principle, it shouldn't output anything which is not a part of a program defined by user. Current approach is very confusing because it hides a first line of the debug output making it looks like the program had no output while it's simply hidden behind "LLVM Emit Object... LLVM Emit Object... MachO Flush..." string and forcing addition of std.debug.print("\n", .{}); to every program.

[RossComputerGuy]

I don't really see this as a bug. Maybe there should be a way to hide or enable the message. However, zig does display this whenever you also do zig build --help which you could argue that it is also "hidden control flow". In reality, it kinda isn't "hidden control flow" as Zig has to emit an object to execute it. As you told Zig to run a file, it has to compile it first.

[nektro]

Zig deletes these strings using standard ansi escape sequences before launching the compiled executable, and it is this runner view not supporting them.

Additionally, you can zig build-exe file.zig and ./file separately if you would like to only get the output of the program.

[obask]

Thanks! I agree this could have been labeled a feature request, but unfortunately, I can't change the label now. It would be great if verbose mode were only activated with the -v option. I understand the initial reason might have been to show that the program is active and not stuck during long compilation, but perhaps this will become unnecessary with an incremental compiler. It's your call, of course; I'm just pointing out aspects that might be confusing to an outsider like myself.

[mikastiv]

Maybe related to #18855

[obask]

related to #18855

It seems that zig build run is more useful compared to zig run, because the latter doesn't understand external dependencies. I'm not sure about its future in more complex projects; perhaps it will be deprecated or reserved for simple shell-like scripts.

[VisenDev]

Possibly related concerns #17821

[andrewrk]

Fixed by #20059