diff options
| author | mlugg <mlugg@mlugg.co.uk> | 2025-08-08 09:13:38 +0100 |
|---|---|---|
| committer | Matthew Lugg <mlugg@mlugg.co.uk> | 2025-08-08 23:14:26 +0100 |
| commit | 5f7a0bbabfde4eeb0ff4f40f0942ef710b6104a1 (patch) | |
| tree | 33d506f40e4f7eef8b423ba1740c77675a0c5428 /src/codegen | |
| parent | 2a8751e37f1e4d978400a95faca05119f17cf598 (diff) | |
| download | zig-5f7a0bbabfde4eeb0ff4f40f0942ef710b6104a1.tar.gz zig-5f7a0bbabfde4eeb0ff4f40f0942ef710b6104a1.zip | |
Sema: fix unreasonable progress node numbers
The "completed" count in the "Semantic Analysis" progress node had
regressed since 0.14.0: the number got crazy big very fast, even on
simple cases. For instance, an empty `pub fn main` got to ~59,000 where
on 0.14 it only reached ~4,000. This was happening because I was
unintentionally introducing a node every time type resolution was
*requested*, even if (as is usually the case) it turned out to already
be done. The fix is simply to start the progress node a little later,
once we know we are actually doing semantic analysis. This brings the
number for that empty test case down to ~5,000, which makes perfect
sense. It won't exactly match 0.14, because the standard library has
changed, and also because the compiler's progress output does have some
*intentional* changes.
Diffstat (limited to 'src/codegen')
0 files changed, 0 insertions, 0 deletions
