From e03095f167cf0cd8c1424bff0de3c0a7b5f66b18 Mon Sep 17 00:00:00 2001 From: Andrew Kelley Date: Wed, 22 Sep 2021 19:00:43 -0700 Subject: 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. --- src/Module.zig | 7 ------- 1 file changed, 7 deletions(-) (limited to 'src/Module.zig') diff --git a/src/Module.zig b/src/Module.zig index 70c90d9c01..861648d689 100644 --- a/src/Module.zig +++ b/src/Module.zig @@ -3758,13 +3758,6 @@ pub fn clearDecl( dep.removeDependency(decl); if (outdated_decls) |map| { map.putAssumeCapacity(dep, {}); - } else if (std.debug.runtime_safety) { - // If `outdated_decls` is `null`, it means we're being called from - // `Compilation` after `performAllTheWork` and we cannot queue up any - // more work. `dep` must necessarily be another Decl that is no longer - // being referenced, and will be in the `deletion_set`. Otherwise, - // something has gone wrong. - assert(mod.deletion_set.contains(dep)); } } decl.dependants.clearRetainingCapacity(); -- cgit v1.2.3