Self-hosted treats `*VaList` different than LLVM does

[elpekenin]

Zig Version

0.15.0-dev.1092+d772c0627

Steps to Reproduce and Observed Behavior

I've noticed that compiler doesn't like an argument of type *VaList in a "normal" function. That is, when breaking some of my code into smaller pieces, compiler complained:

src/root.zig:186:1: error: auto does not support var args
fn printChar(writer: *Writer, ap: *VaList, _: Specifier) Writer.Error!void {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Which, at the very least, is not a very readable message. Wording makes it seems like i tried using ..., which I don't.

My rough understanding is that the problem is not the passing of a *VaList argument, but the related builtins (mostly @cVaArg) emitting different code depending on the calling convention used in the function and auto having no specific information in that regard.

Took the question to discord for a better understanding. After seeing that LLVM backend has no issue with this snippet, @mlugg suggested reporting this as a bug report because:

behavior shouldn't differ between backends; either @cVaArg needs to work here universally, or it needs to error here universally

Expected Behavior

Behavior matching between backends

[mlugg]

This error is emitted by the x86_64 backend when it encounters a usage of @cVaArg in a callconv(.auto) function. This is in a switch on the current calling convention, where .x86_64_sysv is implemented, but .x86_64_win is a TODO.

I hadn't really thought about it before, but I suppose that yes, the lowering for @cVaArg does indeed depend on the C calling convention. Assuming that's true, the way the C varargs builtins look in Zig today cannot work universally, because a usage of @cVaArg doesn't know whether to treat it as .x86_64_sysv or .x86_64_win. Here are some potential solutions I can see:

• Introduce the rule that @cVaArg can, indeed, only be used in a function whose calling convention supports varargs. I don't love this limitation, but it would certainly be the simplest solution to the problem.
• Introduce the rule that varargs builtins always assume callconv(.c), and as such, disallow @cVaStart in functions with different calling conventions. I think this would be a bad choice, since it limits the ABIs you can expose.
• Add a new argument to @cVaArg specifying the calling convention. For instance, @cVaArg(ap, .c). This is the most general/permissive solution, but makes the builtin more awkward to use. However, I don't really mind that tradeoff, because these builtins are very rare to use anyway.
  • Related point: VaList is currently specialised to the compilation's target, but in theory it could depend on the calling convention instead, and in fact does on x86_64! As such, I wonder if, rather than having one global VaList type, there should instead be a method on CallingConvention to get the corresponding VaList type, e.g. my_callconv.VaList(). This, uh, opens up a surprisingly big language design rabbit-hole.

[Vexu]

I thought about this recently when looking into implementing @cVaArg for more targets and my solution was for @cVaStart to select the proper VaList type based on the calling convention. The other builtins would then be able to infer the calling convention from the type.

[alexrp]

Related:

zig/lib/std/builtin.zig

Line 1028 in 70206af

.sh, .sheb => VaListSh, // This is wrong for `sh_renesas`: https://github.com/ziglang/zig/issues/24692#issuecomment-3150779829