aboutsummaryrefslogtreecommitdiff
path: root/src/Compilation.zig
diff options
context:
space:
mode:
authormlugg <mlugg@mlugg.co.uk>2025-08-08 09:13:38 +0100
committerMatthew Lugg <mlugg@mlugg.co.uk>2025-08-08 23:14:26 +0100
commit5f7a0bbabfde4eeb0ff4f40f0942ef710b6104a1 (patch)
tree33d506f40e4f7eef8b423ba1740c77675a0c5428 /src/Compilation.zig
parent2a8751e37f1e4d978400a95faca05119f17cf598 (diff)
downloadzig-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/Compilation.zig')
0 files changed, 0 insertions, 0 deletions