This needs to use translatable diagnostics, but that's something to do in a separate PR

@workingjubilee yes C calls them "variable arguments" but I think it still calls the functions themselves "variadic functions".

A function that takes a variable number of arguments is called a variadic function.

(from https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Variable-Number-of-Arguments.html)

I think the latter is a more unique phrase (i.e. easier to google search lol) and we should keep it. Do you have an example of an error message that calls them "variable arguments"? I searched and couldn't really find anything mentioning either, since C error messages are kinda terse, but I did find this one that calls them "variadic functions":

https://godbolt.org/z/9c79z9j9Y

<source>:10:12: error: cannot pass object of non-trivial type 'std::string' (aka 'basic_string<char>') through variadic function; call will abort at runtime [-Wnon-pod-varargs]
    foo(1, s, 3);
           ^
1 error generated.
Compiler returned: 1

A niladic function would be one that takes zero arguments, a monadic function, one, a dyadic function, two, etc., by extension we arrive at variadic functions for a variable number of arguments. A function using C's ... is indeed a variadic function. However, your example function will be called with 1 fixed argument and an unknown number of variable arguments. It is still a variadic function if no variable arguments are passed at all. It can, in those fixed parameters, accept arguments of types prohibited in the variable arguments. Differing from C's terminology seems fine, but the previous message was incorrect in any case.

I realize this is extremely pedantic, but we really ought to be at least a few notches more pedantic about how we handle varargs.

The preference in C/C compilers handling erroneous cases seems to be literally just calling it ... which also seems fine, since that's what the programmer will actually be looking at. https://godbolt.org/z/81nEEEnjo

In file included from <source>:3:
<source>: In function 'void foo(int, ...)':
<source>:8:26: error: 'float' is promoted to 'double' when passed through '...' [-Werror]
    8 |     float f = va_arg(ap, float);
      |                          ^
<source>:8:26: note: (so you should pass 'double' not 'float' to 'va_arg')
<source>:8:26: note: if this code is reached, the program will abort
cc1plus: all warnings being treated as errors
Compiler returned: 1

Edit: Responding to errs.

To be fair, "can't pass `$ProblematicType` to variadic function" is imprecise (incorrect even, technically speaking) since it's legal to pass a value of $ProblematicType as an argument where the correp. param is "non-variable". E.g. 0f32 in f(0f32, x, y, z) is fine given e.g.fn f(_: f32, ...).

Still, the new phrasing does feel a bit uncommon.

...and this is an important distinction to preserve because some C ABIs are written in such a way that the way the arguments will be inspected in the callee function will be handled uniformly regardless of the number of arguments. In other words, they make it so ... is ABI-compatible with a hypothetical function with the same fixed arguments. So they deliberately conflate "variadic function" with "a function receiving any number of arguments" i.e. including a function with 1 fixed argument or 10 fixed arguments, because the ABIs are identical.

But others are not, and the way varargs are passed has nothing to do with the way other args are passed, so this is in fact completely incompatible. On those platforms, code which conflates these will explode, and some C libraries had to be rewritten for those platforms.

some options:

prefer either of these 👍

In any case (esp. if we were to take the "`...`" one), we might also want to add a secondary highlight to the def site of the CVarArgs with a label to clear up any potential "surprises" (the user might not immediately realize that they were passing something to a CVarArgs list).