Compiler crash #30066

Zig Version

0.16.0-dev.1519+bfe331705

Steps to Reproduce and Observed Behavior

git clone git@github.com:sergz72/zforth.git
zig build

install
└─ install zforth
└─ compile exe zforth Debug native failure
error: Compiler crash context:
(no context)

 thread 9263 panic: reached unreachable code
 /opt2/serg/my/git/Zig/zig/src/Type.zig:1422:27: 0x2ffa95e in abiSizeInner__anon_332219 (main.zig)
 .func_type => unreachable, // represents machine code; not a pointer
 ^
 /opt2/serg/my/git/Zig/zig/src/Type.zig:1272:25: 0x29e374e in abiSize (main.zig)
 return (abiSizeInner(ty, .eager, zcu, {}) catch unreachable).scalar;
 ^
 /opt2/serg/my/git/Zig/zig/src/link/Dwarf.zig:3836:60: 0x44ae074 in updateLazyType (main.zig)
 field_byte_offset += field_type.abiSize(zcu);
 ^
 /opt2/serg/my/git/Zig/zig/src/link/Dwarf.zig:2311:45: 0x3bfefef in updateLazy (main.zig)
 try wip_nav.dwarf.updateLazyType(wip_nav.pt, src_loc, pending_ty, &wip_nav.pending_lazy)
 ^
 /opt2/serg/my/git/Zig/zig/src/link/Dwarf.zig:3476:27: 0x3ad1e20 in updateComptimeNavInner (main.zig)
 try wip_nav.updateLazy(nav_src_loc);
 ^
 /opt2/serg/my/git/Zig/zig/src/link/Dwarf.zig:3024:34: 0x3ad4f7a in updateComptimeNav (main.zig)
 return updateComptimeNavInner(dwarf, pt, nav_index) catch |err| switch (err) {
 ^
 /opt2/serg/my/git/Zig/zig/src/link/Elf/ZigObject.zig:1705:64: 0x30249b2 in updateNav (main.zig)
 } else if (self.dwarf) |*dwarf| try dwarf.updateComptimeNav(pt, nav_index);
 ^
 /opt2/serg/my/git/Zig/zig/src/link/Elf.zig:1697:43: 0x29f043f in updateNav (main.zig)
 return self.zigObjectPtr().?.updateNav(self, pt, nav);
 ^
 /opt2/serg/my/git/Zig/zig/src/link.zig:768:81: 0x24cc9f2 in updateNav (main.zig)
 return @as(*tag.Type(), @fieldParentPtr("base", base)).updateNav(pt, nav_index);
 ^
 /opt2/serg/my/git/Zig/zig/src/link.zig:1505:29: 0x2955efb in doZcuTask (main.zig)
 lf.updateNav(pt, nav_index) catch |err| switch (err) {
 ^
 /opt2/serg/my/git/Zig/zig/src/link/Queue.zig:318:23: 0x292a987 in flushTaskQueue (main.zig)
 link.doZcuTask(comp, tid, task);
 ^
 /home/sergzz/serg/my/git/Zig/zig/lib/std/Thread/Pool.zig:180:50: 0x292b133 in runFn (std.zig)
 @call(.auto, func, .{id.?} ++ closure.arguments);
 ^
 /home/sergzz/serg/my/git/Zig/zig/lib/std/Thread/Pool.zig:293:27: 0x23ac2f0 in worker (std.zig)
 runnable.runFn(runnable, id);
 ^
 /home/sergzz/serg/my/git/Zig/zig/lib/std/Thread.zig:559:13: 0x21ce5a0 in callFn__anon_195807 (std.zig)
 @call(.auto, f, args);
 ^
 /home/sergzz/serg/my/git/Zig/zig/lib/std/Thread.zig:831:30: 0x205f7f9 in entryFn (std.zig)
 return callFn(f, args_ptr.*);
 ^
 ./nptl/pthread_create.c:448:8: 0x7b695d8a3d63 in start_thread (pthread_create.c)
 ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78:0: 0x7b695d9373bb in __GI___clone3 (../sysdeps/unix/sysv/linux/x86_64/clone3.S)

Expected Behavior

Project compiles without compiler crash.

This looks like the same issue as in https://github.com/ziglang/zig/issues/24882

As a workaround, changing this line (github.com/sergz72/zforth@f2a50d9656/src/forth_words.zig (L196))

--- a/src/forth_words.zig
+++ b/src/forth_words.zig
@@ -193,7 +193,7 @@ pub const ForthWordError = error {

 pub const ForthWordType = union(enum) {
 Code: []*ForthWord,
- SingleIr: std.meta.Tuple(&.{IrOperation, fn(Allocator,Context) anyerror!void}),
+ SingleIr: std.meta.Tuple(&.{IrOperation, *const fn(Allocator,Context) anyerror!void}),
 CompileOnly: fn(Allocator,Context) void,
 InterpretOnly: fn(Allocator,Context) void,
 };

makes it possible for the compiler to continue without crashing, although this surfaces several other unrelated compile errors in the project:

src/main.zig:28:58: error: unable to resolve comptime value
 var compiler = try forth_compiler.ForthCompiler.init(allocator, 1024);
 ^~~~~~~~~
src/main.zig:28:57: note: call to function with comptime-only return type '@typeInfo(@typeInfo(@TypeOf(forth_compiler.ForthCompiler.init)).@"fn".return_type.?).error_union.error_set!forth_compiler.ForthCompiler' is evaluated at comptime
 var compiler = try forth_compiler.ForthCompiler.init(allocator, 1024);
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
src/forth_compiler.zig:18:64: note: return type declared here
 pub fn init(allocator: Allocator, data_stack_size: usize) !ForthCompiler {
 ^~~~~~~~~~~~~
src/forth_compiler.zig:16:14: note: struct requires comptime because of this field
 context: Context,
 ^~~~~~~
src/forth_words.zig:85:41: note: struct requires comptime because of this field
 current_code: std.ArrayListUnmanaged(*ForthWord),
 ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~
/home/ian/src/zig/lib/std/array_list.zig:585:16: note: struct requires comptime because of this field
 items: Slice = &[_]T{},
 ^~~~~
src/forth_words.zig:203:11: note: struct requires comptime because of this field
 type: ForthWordType,
 ^~~~~~~~~~~~~
src/forth_words.zig:195:11: note: union requires comptime because of this field
 Code: []*ForthWord,
 ^~~~~~~~~~~~
src/forth_words.zig:197:18: note: union requires comptime because of this field
 CompileOnly: fn(Allocator,Context) void,
 ^~~~~~~~~~~~~~~~~~~~~~~~~~
src/forth_words.zig:197:18: note: use '*const fn (mem.Allocator, forth_words.Context) void' for a function pointer type
src/forth_words.zig:198:20: note: union requires comptime because of this field
 InterpretOnly: fn(Allocator,Context) void,
 ^~~~~~~~~~~~~~~~~~~~~~~~~~
src/forth_words.zig:198:20: note: use '*const fn (mem.Allocator, forth_words.Context) void' for a function pointer type

In the following test program, the Zig compiler accepts function parameters without pointers everywhere except in tuple definitions, where it leads to a compiler crash. Should there be some consistency? Either compiler should accept a function as a parameter everywhere or nowhere. Am I right?

conststd=@import("std");constUnion1=union(enum){f1:fn(usize)usize,f2:std.meta.Tuple(&.{usize,constfn(usize)usize})};fntest1(f:fn(usize)usize)usize{returnf(10);}fntest_fn(x:usize)usize{returnx+1;}pubfnmain()!void{std.debug.print("{}\n",.{test1(test_fn)});constu=Union1{.f1=test_fn};std.debug.print("{}\n",.{u.f1(5)});constu_2=Union1{.f2=.{20,&test_fn}};std.debug.print("{}\n",.{u_2.f2[1](u_2.f2[0])});}

Yes, a compiler crash is always a bug.

Seems like this was fixed in #31403?