Zig: 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.