Pedantic / warning

Anthon · April 19, 2026, 9:40am

I might be missing something, but I would like to have had a --pedantic or --warning option on Zig 0.15 (zig build and zig build-exe) to find things that have been deprecated in 0.15 or earler version but still work (in 0.15). I am referring to language constructs that might no longer work in some future version, some expected library changes (managed versions). Here is why:

I have code that I started a few years ago, and that I have upgraded for various compiler/library changes over the years. I have test for this code, but as soon as I start making changes for a new version (such as now for 0.16), I cannot run those tests until everything has been upgraded/fixed for the new version and it compiles again. In this particular case, after making several changes for 0.16 based on what the compiler complained about, I found that in some places I still use .{} (from a pre-0.14 period), instead of .empty ( which I use for any new code I write).

I would much prefer to have changed all of the .{} before doing any of the 0.16 changes, so that I could still run my tests (with 0.15) after that bunch of changes. Now, in order to allow for immediate testing, I have to roll-back my 0.16 specific changes, update .{} to .empty everywhere applicable, run tests. And after that re-apply the 0.16 specific changes necessary, that I previously found, after that fixing the next thing 0.16 complains about. And I have to hope that I don’t find anything else I could have done in 0.15, that I makes me want to roll-back to 0.15 only code, so I can test everything before proceeding.

I could of course re-read the release notes of the last few releases ( re-read because I tend to not understand and/or appreciate the significance of some of the changes on first reading), And then read through all of my 0.15 code, and update it before switching to 0.16. But it is easy to miss things and it woud be nice if the compiler helped with finding at least some of these depreciations, I would also be less likely to postpone “fixing” these until things no longer compile, if I had some automated way of finding the majore culprits.

I have no idea how difficult this is to implement. Or if this rather should be different (sub)command for zig or an option to the commands build and build-exe. It could also be some separate tool. For me this also doesn’t have to be in the first release of a new minor version (0.X.0), but it would be nice to have it later on, to clean up code before upgrading.

Is there some tool or zig option that I missed, that can analyse my 0.15 Zig code?

npc1054657282 · April 19, 2026, 9:46am

My idea is relatively simple: it is reasonable to forbid warnings during a release build, but not in the debug build. Some minor issues during debugging are not enough to interrupt testing of the entire process.

vulpesx · April 19, 2026, 9:59am

zig doesn’t have warnings, and they are not planned. The reasoning being warnings can be ignored.

There is a plan to still out put an exe/lib/obj when an error occurs, letting you run code up to the point of the error where it will panic.

This fulfils the use case of warnings, running code while ignoring pedantics and even hard errors (can your warnings do that :p) for the purposes of development, but still ensures they cannot be ignored easily as a pedantic panic will still remain.

rpkak · April 19, 2026, 10:04am

github.com/ziglang/zig

`@deprecated()` builtin

opened 12:32AM - 09 Feb 25 UTC

kristoff-it

proposal accepted

## Motivation It's already an established pattern in the Zig ecosystem to depre…cate declarations first via a doc comment, and after a while by turning the old decl into a `@compileError` once the deprecation "grace period" is over, to then finally delete the decl altogether after some more time. Currently a user that is interested in discovering early which APIs are being deprecated must grep the codebase for the word, find the decl the comment refers to, and figure out if and where its being used (directly or not) in the codebase. Conversely, a library author that wants to maintain backwards compatibility (i.e. avoid a major version bump for a v1 package) will not want to set deprecated decls to `@compileError` as that would be a compatibility breakage, never giving users an opportunity to leverage compile errors to migrate their API usage. It is possible today to implement a better solution entirely in userland: ```zig // build.zig fn build(b: *std.Build) void { const opts = b.addOptions(); opts.addOption("deprecated", b.option( bool, "deprecated", "turn deprecated decls into compile errors", ) orelse false); } ``` ```zig // root.zig const options = @import("options"); fn oldFoo() void { if (options.deprecated) { @compileError("deprecated, use newFoo()"); } } /// Deprecated: use `GenericWriter` const Writer = if (options.deprecated) @compileError("deprecated, use `GenericWriter`") else GenericWriter; ``` Running `zig build -Ddeprecated` will turn deprecated decls in compile errors giving both a nice compiler-driven upgrade experience to users, while letting library authors maintain backwards compatibility. This pattern seems so useful that might be worth enshrining it as a standardized practice. ## Proposal Introduce a `@deprecated()` builtin and a new `-fdeprecated` compiler flag to be used like so (this is a contrived example to showcase the workflow): ```zig // main.zig const std = @import("std"); const num = @deprecated(10); pub fn main() void { std.debug.print("num: {}\n", .{num}); } ``` ``` $ zig run main.zig num: 10 ``` ``` $ zig run main.zig -fdeprecated main.zig:3:13: error: found deprecated code const num = @deprecated(10); ^~~~~~~~~~~~~~~ referenced by: main: main.zig:6:34 posixCallMainAndExit: zig/lib/std/start.zig:647:22 4 reference(s) hidden; use '-freference-trace=6' to see all references ``` A less contrived example would be the current deprecation of `std.time.sleep` in the Zig standard library: ```zig /// Deprecated: moved to std.Thread.sleep pub const sleep = std.Thread.sleep; ``` ```zig pub const sleep = @deprecated(std.Thread.sleep); ``` A second example: using `@deprecated` in a function body: ```zig const Strategy = enum { greedy, expensive, fast }; fn compute(comptime strat: Strategy, comptime foo: bool, bar: usize) void { switch(strat) { .greedy => { // This strategy turned out to be bad when foo is false, // use the fast strategy instead. if (!foo) @deprecated(); runGreedy(foo, bar); }, .expensive => runExpensive(foo, bar), .fast => runFast(foo, bar), } } ``` Lastly, since `@deprecated` conveys intent more precisely, tooling like LSPs and linters could offer diagnostics about deprecation automatically to the user in a more streamlined fashion than with the full userland solution. A branch with `@deprecated` implemented can be found here: https://github.com/kristoff-it/zig/tree/deprecated-proposal ([diff](https://github.com/ziglang/zig/commit/da6471a209a495494074420886c70984357a8436))

(accepted proposal; not implemented yet)

Anthon · April 19, 2026, 10:08am

I don’t see how that would help with finding deprecations in any way, for those running is not really necessary. Maybe the option (if added) should be --show-used-deprecations.

BTW, in my experience Zig already generates an executable on error: it is just an empty file with exec persmissions:

zig/zigclc » ls -lrt | tail -2
-rw-r--r--  1 anthon users 3169832 Apr 19 11:23 zigclc.zig
-rwxr-xr-x  1 anthon users       0 Apr 19 11:23 zigclc*

This is on macOS, and you can actually run the file, but nothing happens.

vulpesx · April 19, 2026, 10:12am

Ah sorry, I can’t read apparently

the proposal linked above seems to be what you want, it is accepted, and was implemented temporarily but reverted due to bugs.

what I said is planned, it is not implemented

Anthon · April 19, 2026, 10:18am

I followed that when it was introduced. But I always thought that to be for function (and struct/unions) changes.. I.e. you should no longer call XYZManaged although it still functions in the current version.

It seems to me that the deprecations of .{} in favour of .empty, cannot be marked up with @deprecation in a library. But maybe the latter can be put into some compiler source position dealing with the .{} instead.

rpkak · April 19, 2026, 10:21am

For context on the exe/lib/obj output on error: I don’t think there exists an issue about this, but see e.g. this comment:

github.com/ziglang/zig

`build-exe` creates an empty executable file on compilation errors

opened 01:10AM - 17 May 23 UTC

closed 01:37AM - 23 Jul 23 UTC

GreenRecycleBin

### Zig Version 0.10.1 ### Steps to Reproduce and Observed Behavior ```consol…e $ cat <<EOF > stack_trace.zig pub fn main() void { foo(0); } fn foo(x: i32) void { if (x >= 5) { bar(); } else { bang2(); } } fn bar() void { if (baz()) { quxx(); } else { hello(); } } fn baz() bool { bang1(); } fn quxx() void { bang2(); } fn hello() void { bang2(); } fn bang1() bool { return false; } fn bang2() void { @panic("PermissionDenied"); } EOF $ file stack_trace stack_trace: cannot open `stack_trace' (No such file or directory) $ zig build-exe stack_trace.zig stack_trace.zig:22:10: error: value of type 'bool' ignored bang1(); ~~~~~^~ stack_trace.zig:22:10: note: all non-void values must be used stack_trace.zig:22:10: note: this error can be suppressed by assigning the value to '_' referenced by: bar: stack_trace.zig:14:9 foo: stack_trace.zig:7:9 remaining reference traces hidden; use '-freference-trace' to see all reference traces $ file stack_trace stack_trace: empty $ ls -l stack_trace -rwxr-xr-x@ 1 me staff 0 May 17 09:07 stack_trace ``` ### Expected Behavior `build-exe` does not create any files on compilation errors, similar to other compilers, e.g., GCC.

rpkak · April 19, 2026, 10:24am

I see. Maybe doing something like size: usize = @deprecated(0), and pub const empty: TheType = .{ .size = 0 } could work.

vulpesx · April 19, 2026, 10:24am

I couldnt find an issue either, but andrew has talked about it in at least one livestream