add c-variadic function definitions

[folkertdev]

I think this has all of the raw material, but needs polishing.

Here is a draft of the stabilization report, for additional context: https://hackmd.io/@Q66MPiW4T7yNTKOCaEb-Lw/S1iI3WIwZg

Tracking issue: rust-lang/rust#44930

Stabilization:

• Stabilize c-variadic function definitions rust#155697

[ehuss]

I think the rule items.fn.params.varargs will need to be updated, since it says it can only be used in an external block.

View changes since this review

[folkertdev]

The varargs_without_pattern is now reported in dependencies (on nightly).

I've pushed some tweaks, I'm now planning to submit a stabilization PR in coming days, so if you could look at this again that would be helpful.

[ehuss]

It looks like from rust-lang/rust#155974 that there is an intent to make this unavailable on certain targets. I don't think we've ever done something like that, and I'm not sure how we're going to document that. I suppose there will be a rule. It will need to be careful to distinguish that it is a compile error during validation. Unfortunately we don't define that as a specific phase in the reference, so I'm not sure how we should approach that.

[folkertdev]

I don't think this is very different from https://doc.rust-lang.org/beta/unstable-book/language-features/asm-experimental-arch.html. Consequently the page on inline assembly specifies https://doc.rust-lang.org/nightly/reference/inline-assembly.html?highlight=assemb#r-asm.stable-targets.

So we could have

Support for c-variadic function definitions is stable on the following architectures:

• x86 and x86-64
• arm
• aarch64 and arm64ec
• ...

The compiler will emit an error if ... is used in a function definition on an unsupported target.

Also spirv and bpf just fundamentally do not support this feature, so there you'd always get an error.

[folkertdev]

The merge of the stabilization PR is now only blocked on the additions to the reference here (I'm not sure that is really needed, previously features have been merged with a reference PR that was "far enough along").

I've tried to address comments here as much possible now.

I'd be happy to look at this together in the reference office hours if they are at a somewhat european-friendly time.

View changes since this review

[ehuss]

Some quick nits.

View changes since this review

[DanielEScherzer]

@rustbot label -S-waiting-on-stabilization

Stabilization merged in rust-lang/rust#155697

[folkertdev]

Now that c_variadic_naked_functions (rust-lang/rust#159746) is in FCP, this section needs to be extended. Do we just do that now, wait for FCP to be over, or do it in a separate PR?

I was thinking of something like this:

A variable argument list is only accepted on [naked functions] for the ABI strings that are listed in [items.extern.variadic.conventions].

```rust
#[unsafe(naked)]
unsafe extern "win64" fn variadic_win64(_: u32, _: ...) -> u32 {
    core::arch::naked_asm!(
        r#"
        push    rax
        mov     qword ptr [rsp + 40], r9
        mov     qword ptr [rsp + 24], rdx
        mov     qword ptr [rsp + 32], r8
        lea     rax, [rsp + 40]
        mov     qword ptr [rsp], rax
        lea     eax, [rdx + rcx]
        add     eax, r8d
        pop     rcx
        ret
    "#,
    )
}
```

[items.extern.variadic.conventions]: ../items/external-blocks.md#items.extern.variadic.conventions
[naked functions]: ../attributes.md#attributes.codegen.naked

View changes since the review

[traviscross]

Thanks. Let's do that in a separate PR (as this one needs to merge as the stabilization has already merged).