Proposal: better tooling to inspect import/analysis graphs

[mitchellh]

We've been working on improving build times in the Ghostty project for both the build binary as well as final artifacts. At the scale of the Ghostty project with hundreds of Zig files importing across each other, it's very difficult to determine where imports are triggering downstream recompilations.

This applies to both build binaries and runtime artifacts.

A real example from our [work-in-progress] migration to Zig 0.15: something changed in Zig 0.15 so that imports became a bit more eager, causing an "import outside of build root" error that didn't happen on Zig 0.14 (because the import is never reached). This was the fix: ghostty-org/ghostty@d7cfc51

To determine that, I manually grepped for imports and traced them myself and made the guess that this was happening. Thankfully I was right. This has been a repeat occurrence.

This also applies to decls as well. It'd be nice to get the -freference-trace output for all instances of all decls and be able to do general graph traversal and search on that. But the primary culprit for me is imports.

I think with incremental compilation this sort of debug tooling will be even more important, since minimizing this will likely be the key to faster and faster compilation.

I'm sorry, this issue lacks a formal proposal and is instead more of a problem statement. If this should go elsewhere to discuss further I'm happy to move it.

[mlugg]

I think it would make sense for file-level errors to show a reference trace based on the import path. We already output this information (albeit not in the reference trace) for "file in multiple module" errors:

b.zig:1:1: error: file exists in modules 'c' and 'a'
b.zig:1:1: note: files must belong to only one module
b.zig:1:1: note: file is the root of module 'c'
b.zig:1:19: note: file is imported here
const c = @import("c.zig");
                  ^~~~~~~
a.zig:1:19: note: which is imported here by the root of module 'a'
const b = @import("b.zig");
                  ^~~~~~~

We could quite easily use similar logic to put the import chain into the reference trace for other whole-file errors.

[mitchellh]

@mlugg Note this isn't only for errors. I'd like to do this for optimizing which file edits trigger rebuilds in other files. The error output itself improving would help too, though.

[andrewrk]

That could be interesting metadata to add to the build system webui (the one that lists only things that had to be recompiled on update). The "roots" could be annotated so you can see not only what had to be rebuilt but why.