panic trace from `inline fn` with function call in argument position points caret at argument, not outer function call

[rohlem]

Zig Version

0.14.0-dev.2597+252c20310

Steps to Reproduce and Observed Behavior

repro .zig:

pub inline fn uIn(_: void, _: void, _: void) void {
    unreachable;
}
pub fn u(_: void, _: void, _: void) void {
    unreachable;
}
pub fn f() void {}
pub inline fn fIn() void {}
test {
    //uIn({}, {}, {}); //correct caret
    //u(f(), f(), {}); //correct caret (+ additional stack level because u isn't inline)
    uIn(f(), f(), {}); //points to last argument function call (second argument)
    //uIn(f(), fIn(), {}); //similarly wrong (points fIn())
}

output of zig test .zig:

thread 14668 panic: reached unreachable code
...\.zig:12:15: 0x7ff763c21030 in test_0 (test.exe.obj)
    uIn(f(), f(), {}); //points to last argument function call (second argument)
              ^
...\zig-windows-x86_64-0.14.0-dev.2597+252c20310\lib\compiler\test_runner.zig:209:25: 0x7ff763c911cf in mainTerminal (test.exe.obj)
        if (test_fn.func()) |_| {
                        ^
...\zig-windows-x86_64-0.14.0-dev.2597+252c20310\lib\compiler\test_runner.zig:58:28: 0x7ff763c8aaa9 in main (test.exe.obj)
        return mainTerminal();
                           ^
...\zig-windows-x86_64-0.14.0-dev.2597+252c20310\lib\std\start.zig:475:53: 0x7ff763c8a547 in WinStartup (test.exe.obj)
    std.os.windows.ntdll.RtlExitUserProcess(callMain());
                                                    ^
???:?:?: 0x7ffbdfcd53df in ??? (KERNEL32.DLL)
???:?:?: 0x7ffbe0ee485a in ??? (ntdll.dll)
error: the following test command failed with exit code 3:
...\zig\o\e954cf45828282860d8530bcb770fbb5\test.exe --seed=0x1da16a86

The caret points at the last function call in the argument position (uIn(f(), >f(), {});), even though that's not where the panic originates from.

Expected Behavior

The encountered unreachable is within uIn, so the caret should arguably point at the outer call (uIn>(f(), f(), {});).
Maybe there is some technical reason (we don't have a stack level for the inline function afterall), however since the caret is correct in case of no argument function calls, I suspect that the compiler is simply missing (or misordering?) a progress sequence point / marker throughout the function.
That is, after all arguments have been computed (calls to f() have finished), a panic trace should point at the outer function call.

I first considered the "error message" template, but since it mentions compile errors and the trace is generated at runtime, I now chose "bug" instead.
FWIU the most likely cause is incorrect / suboptimal generated debug info, so "bug" felt more appropriate in that regard as well.

[mlugg]

Hah, that's funny, I noticed this bug in my current WIP branch. I might have fixed it locally -- will take a look at some point.