diff options
| author | mlugg <mlugg@mlugg.co.uk> | 2024-01-07 00:42:30 +0000 |
|---|---|---|
| committer | mlugg <mlugg@mlugg.co.uk> | 2024-01-23 21:19:53 +0000 |
| commit | 06d8bb32e3edfb4a26c6d3ecdf198574f4bd3f87 (patch) | |
| tree | c71cc2ab5af1f24f224031f947c9ac0396df2562 /src/main.zig | |
| parent | ae845a33c04fb287ae5a7445743c2b570e40ca1f (diff) | |
| download | zig-06d8bb32e3edfb4a26c6d3ecdf198574f4bd3f87.tar.gz zig-06d8bb32e3edfb4a26c6d3ecdf198574f4bd3f87.zip | |
InternPool: introduce TrackedInst
It is problematic for the cached `InternPool` state to directly
reference ZIR instruction indices, as these are not stable across
incremental updates. The existing ZIR mapping logic attempts to handle
this by iterating the existing Decl graph for a file after `AstGen` and
update ZIR indices on `Decl`s, struct types, etc. However, this is
unreliable due to generic instantiations, and relies on specialized
logic for everything which may refer to a ZIR instruction (e.g. a
struct's owner decl). I therefore determined that a prerequisite change
for incremental compilation would be to rework how we store these
indices.
This commit introduces a `TrackedInst` type which provides a stable
index (`TrackedInst.Index`) for a single ZIR instruction in the
compilation. The `InternPool` now stores these values in place of ZIR
instruction indices. This makes the ZIR mapping logic relatively
trivial: after `AstGen` completes, we simply iterate all `TrackedInst`
values and update those indices which have changed. In future, if the
corresponding ZIR instruction has been removed, we must also invalidate
any dependencies on this instruction to trigger any required
re-analysis, however the dependency system does not yet exist.
Diffstat (limited to 'src/main.zig')
0 files changed, 0 insertions, 0 deletions
