Detecting dead code?

tsdtas · December 2, 2025, 10:05am

The Zig compiler is great at being lazy. Top notch couch enjoyer. World class stayer in bed.

Sometimes that supreme laziness leads to files and functions just sitting there in my code repositories, doing nothing, blissfully ignored by the compiler and forgotten by the human. Time passes, code rots, APIs change, still it hangs on, until one day you rediscover it, try calling it, and suddenly you’re covered in compiler vomit.

How do you deal with detecting dead code in Zig projects?

Is it possible to tell the difference between conditionally excluded code that is “not used in the current build” and code where “there is no way to reach this with any combination of build options”?

vulpesx · December 2, 2025, 10:18am

Currently, there isn’t a way to see all unused things.

If you want to know if something specific is not being used with a particular target/options, put some incorrect code in it. If you get a compile error, it is being used, otherwise it’s not.

If you want to know if something specific is being used at all, if your editor supports goto-references (likely through zls), you can use that to see if it’s being used.

This would be a nice tool to have, and should be somewhat easy to add to zls, it already has the information on a per-file basis, though not yet on a whole project basis.

matklad · December 2, 2025, 10:21am

github.com/tigerbeetle/tigerbeetle

src/tidy.zig

main


      
          /// Detects unused constants and functions.
          ///
          /// This is a one-side heuristic: there might be false negatives, but no false positives.
          ///
          /// Current algorithm:
          /// - Two passes.
          /// - Pass 1: count how many times each identifier is mentioned in the file.
          /// - Pass 2: warn about any unique identifier which is a non-public declaration.
          ///
          /// At the moment, this is implemented using only the lexer, without looking at the AST, as that
          /// seemed simpler.
          fn tidy_dead_declarations(
              tree: *const std.zig.Ast,
              used: *UsedDeclarations,
          ) ?[]const u8 {
              assert(used.count() == 0);
              defer used.clearRetainingCapacity();
          
              var identifier_start: ?std.zig.Ast.ByteOffset = 0;
              inline for (.{ .fill, .check }) |phase| {

This file has been truncated. show original

pachde · December 2, 2025, 4:57pm

Not sure this is a problem that needs a solution. If you call something that’s gone bad, you just throw it away and make a new one just like some leftovers in the fridge you left too long.

Code coverage is a tool that is commonly used to root out unimportant/unused/obsolete parts of a codebase.

jumpnbrownweasel · December 2, 2025, 5:15pm

I agree. It is more an issue during dev, because I assume all the code is being compiled since that’s what I’m used to with other languages. It is a matter of adapting my mindset to lazy compilation and adding a test very soon after I write new code. Plus using the tools you mentioned (code coverage, etc) earlier in the dev cycle (although I admit I still haven’t done that).

tsdtas · December 3, 2025, 7:32am

That’s a really neat solution! Might even call it tidy, if I was trying to be funny…

tsdtas · December 3, 2025, 7:34am

It is a matter of adapting my mindset to lazy compilation and adding a test very soon after I write new code.

It might be. There’s definitely some learning to be had in the “just because your code exists doesn’t mean anything knows it exists” state of things, which seems to be a problem that’s unique to Zig in the programming languages I have experience with.

tsdtas · December 3, 2025, 7:37am

Do we have any guides on using code coverage tools with Zig?

I tried messing around with kcov for half an afternoon and found it difficult to get accurate coverage reports. The lazy compilation model meant I got much higher results than expected, but that was because unreferenced code was being omitted, while referenced code was generally referenced by tests.

Admittedly I haven’t really deep dived on it, so I don’t have specific questions to ask. But that’s been my experience.

Thank you everyone for the ideas.

chung-leong · December 3, 2025, 10:21am

I see this more as an issue of syntax highlighting. Currently we don’t get any indication when a symbol goes unreferenced:

Where as in JavaScript:

jumpnbrownweasel · December 3, 2025, 3:39pm

This is confirmed here under “A caveat worth noting”.

So the only solutions are:

Write a custom tool as in the code @matklad posted above.
Manually check that you test every function.