zig

commit e444e69dc4f9e6a1f25f6081bd0cd4d45f4c9c93 (tree)
parent 4985abcc494cc545e34b164fe12de592cf1b50f4
Author: Jakub Konka <kubkon@jakubkonka.com>
Date:   Fri, 25 Mar 2022 17:31:22 +0100

dwarf: do not use `Type.errorSetNames()` for inferred error sets

Otherwise, we risk tripping an assertion in `Type.errorSetNames()`
in case the inferred error set was not yet fully resolved. This so
far only surfaced when Dwarf triggers recursive analysis of an
error set as part of emitting debug info for an error union.

Diffstat:
M
src/link/Dwarf.zig
 | 
13
++++++++++++-

1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/link/Dwarf.zig b/src/link/Dwarf.zig
@@ -1117,7 +1117,18 @@ fn addDbgInfoType(
             // DW.AT.const_value, DW.FORM.data8
             mem.writeInt(u64, dbg_info_buffer.addManyAsArrayAssumeCapacity(8), 0, target_endian);
 
-            const error_names = if (ty.isAnyError()) module.error_name_list.items else ty.errorSetNames();
+            const error_names = blk: {
+                if (ty.isAnyError())
+                    break :blk module.error_name_list.items;
+                // TODO not quite sure about the next one, but if I don't do this, I risk
+                // tripping an assert in `Type.errorSetNames` in case the inferred error set
+                // was not yet fully resolved. This so far only surfaced when this code would
+                // schedule analysis of an error set part of some error union.
+                if (ty.tag() == .error_set_inferred)
+                    break :blk ty.castTag(.error_set_inferred).?.data.errors.keys();
+                break :blk ty.errorSetNames();
+            };
+
             for (error_names) |error_name| {
                 const kv = module.getErrorValue(error_name) catch unreachable;
                 // DW.AT.enumerator