aboutsummaryrefslogtreecommitdiff
path: root/src/Compilation.zig
diff options
context:
space:
mode:
authorAndrew Kelley <andrew@ziglang.org>2021-09-22 19:00:43 -0700
committerAndrew Kelley <andrew@ziglang.org>2021-09-22 19:05:56 -0700
commite03095f167cf0cd8c1424bff0de3c0a7b5f66b18 (patch)
tree5981b50b570382137f1cf4c1eb2f528cc6962f21 /src/Compilation.zig
parentd86678778a6bcc31dc3cb92a286c278de1214c38 (diff)
downloadzig-e03095f167cf0cd8c1424bff0de3c0a7b5f66b18.tar.gz
zig-e03095f167cf0cd8c1424bff0de3c0a7b5f66b18.zip
stage2: remove 2 assertions that were too aggressive
* `Type.hasCodeGenBits` this function is used to find out if it ever got sent to a linker backend for lowering. In the case that a struct never has its struct fields resolved, this will be false. In such a case, no corresponding `freeDecl` needs to be issued to the linker backend. So instead of asserting the fields of a struct are resolved, this function now returns `false` for this case. * `Module.clearDecl` there was logic that asserted when there is no outdated_decls map, any dependants of a Decl being cleared had to be in the deletion set. However there is a possible scenario where the dependant is not in the deletion set *yet* because there is a Decl which depends on it, about to be deleted. If it were added to an outdated_decls map, it would be subsequently removed from the map when it gets deleted recursively through its dependency being deleted. These issues were uncovered via unrelated changes which are the two commits immediately preceding this one.
Diffstat (limited to 'src/Compilation.zig')
0 files changed, 0 insertions, 0 deletions