Don't stop compilation if compileLog is used

[data-man]

@compileLog is a very useful auxiliary function and I wonder why the compilation should stop.

[data-man]

Note: when #5348 will merged this issue will have a special meaning.

[squeek502]

I think having it fail compilation by default is good since it then encourages library developers, etc to keep @compileLog out of their libraries, but it would be nice to have some sort of option (like a compile flag) to allow compilation to succeed with @compileLog statements for local debugging purposes.

[pixelherodev]

compileLog erroring and the lack of warnings are both deliberate design decisions. If something isn't enough of a priority to warrant an error, it should not be printed out IMO.

[data-man]

Another proposals:

• add logLevel parameter to @compilerLog
• @compilerError == @compilerLog(.Error, message)
• add compilerLog(comptime logLevel, comptime values: var) to std.debug
• add compilerError(comptime values: var) to std.debug
• etc. (e.g. compilerInfo, compilerWarn, ...)

[CurtisFenner]

I don't think separating the @compilerLogs into "log levels" makes sense.

As others have mentioned, Zig is choosing to avoid a concept of "warning", and instead encourage libraries to make bad uses illegal. (I think it's unlikely you can detect most bad uses at comptime anyway, you'd most likely need a wider static analysis)

In addition, it could get noisy. Some libraries may more liberally use some log levels, and you probably don't care about most of them when you're "raising" the level of logs printed.

I do think there are times when there are "interesting" logs that don't indicate a problem that you might still sometimes want to inspect, perhaps when something is behaving strangely or you're trying to figure out all of the ways a comptime library is being used.

Perhaps something like this:

• Rename @compileLog to @compileError
• Add @compileLog(tag: []const u8, message: []const u8).
  By default, this does nothing.
  But, when compiling with a flag --show-compile-logs tag with a matching tag they will appear. That way you could, for example, --show-compile-logs special-dsl-debugging if you want to get a more detailed view of what a complicated comptime DSL library is doing.

On the other hand, using a tag might be a mistake, since it might encourage everyone to just use a tag called "warn". So alternatively it could be filtered to a source file, like --show-compile-logs library/special-dsl.zig, which would only show @compileLogs emitted from within that DSL library.

It might also be interesting to allow @compileError to optionally dump all of the logs associated with a given tag/file that were made up to that point, so that complicated libraries can show more context without having to do a lot of comptime log accounting.

And perhaps like the existing @compileLog, maybe compiling with --show-compile-log would not produce any artifacts/run any tests (to encourage you to only run it when debugging a problem and not as a warning system).

[SpexGuy]

Another important benefit is that the current behavior enables incremental compilation. A major drawback of incremental compilation in other languages is that you don't see warnings for compilation units that don't get recompiled. Since Zig's unit of incremental compilation is a declaration, it's important that we don't have this problem. We solve it by not having warnings, so either something is printed and compilation fails or compilation succeeds and nothing is printed. This behavior has to extend to compileLog as well, in order to see this benefit.

[data-man]

The explanation step by step:

• I need to debug the comptime variables
• and I'm using @compileLog for that.
• but I can't test the application because the compilation is stopped
• so I've commented all lines that contains @compileLog

The important benefit is that @compileLog's messages aren't displayed in the compiled application.

[g-w1]

This is not the case fixed in stage2 right now.

[g-w1]

Sorry, it doesn't happen in stage2 right now:
$ cat test.zig
export fn _start() noreturn {
func();
@compilelog(.here);
unreachable;
}

fn func() void {
@compilelog(.here2);
}
$ ./zig build-exe test.zig -fno-LLVM
test.zig:3:5: error: found compile log statement
test.zig:8:5: note: also here

Compile Log Output:
@as(@type(.EnumLiteral), .here)
@as(@type(.EnumLiteral), .here2)
$

It errors out at the end of compilation (but still finishes), but a special compile log buffer is kept that stores the output. Is the best of both worlds IMO. And the error is only shown if there are no other compilation errors.

[squeek502]

That's the same behavior as stage1, just a different format:

$ zig build-exe 5469.zig
| here
| here2
./5469.zig:3:5: error: found compile log statement
    @compileLog(.here);
    ^
./5469.zig:8:5: error: found compile log statement
    @compileLog(.here2);
    ^

This proposal is to (imo, optionally) make it possible to stop the error: found compile log statement compile errors from occuring (i.e. allow the build to succeed, emit the resulting exe, etc).

[g-w1]

Ah sorry for the misunderstanding, but with the incremental model of stage2, it will emit an exe even with these compile log errors. (At least I think it should ...)
Ignore my previous comments, I was operating off false memory, sorry about that. This would be very easy to implement in stage2 though.