Is there a way today (from build.zig) to detect which .zig files were actually touched by the compiler, so I could fail the build if files exist under e.g. src/ that weren’t included?
Use case:
If not, would an opt-in build check like this make sense?
related topic:
Thanks for the link. I think that discussion is related in principle, but it’s more granular than what I’m asking about.
I’m not asking for dead-code analysis or for unused functions to be typechecked.
I’m only talking about a file-level check: if a .zig file exists under a user-specified directory and was never imported or never entered the compilation graph for a given build step, then error (opt-in).
No inspection of code inside the file, no requirement that all branches are evaluated, just “was this file ever imported at all”.
I also imagine this being useful only for specific steps (for example zig build test), not necessarily for all builds, to avoid multi-target or flag issues.
What do you mean with this, catching if you have some code but forgot to re-export it?
If so there still could be conditional code that re-exports it through some other intermediary sometimes, so I don’t understand how this check would be possible with a single build step without check all the possible build options, etc.
Hmm I guess you want a check that allows you to say given this buildstep, assert that this list of files has been touched/evaluated by the compiler?
So code that uses this checking wouldn’t use conditional code import, because it would trigger failure / wouldn’t work with these checks.
Yes, exactly. I want the compiler to error somehow if I forgot to re-export files.
Because this isn’t something you’d want the compiler to always do, I thought it would make sense as an opt-in build step.
My internal understanding of how the compiler tracks files during a build isn’t great, but it seems plausible that it already knows which files were touched, and that this could be compared against files found in a directory.
I mainly want this when running zig build test --watch, so I don’t accidentally delete a re-export or forget to add one in the first place. That way, when adding new files or refactoring source code, any forgotten files would show up as errors.
Zig’s lazy evaluation model makes this a nontrivial problem to solve in general. You can’t know if a file is excluded from the build due to the current build configuration or it truly is an orphan file, without analyzing the source tree under every possible build configuration. This is fine if you only support one or two target triples, but there’s a lot of possible target combinations.
There’s an issue tracking how to handle this, since it affects more than just dead files.
Maybe you could rig something up with iterating over type names in the module root file in the mean time?