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.

1 files changed, 0 insertions, 7 deletions

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();