stabilize c_variadic_naked_functions

[folkertdev]

tracking issue: #148767
reference PR: rust-lang/reference#2321

Stabilization report

Summary

Stabilize the ability to use #[unsafe(naked)] functions to define c-variadic functions. These c-variadic naked functions accept the same set of ABIs as c-variadic foreign functions, this set is larger than what we currently accept for c-variadic definitions.

#[unsafe(naked)]
unsafe extern "aapcs" fn variadic_aapcs(_: f64, _: ...) -> f64 {
    core::arch::naked_asm!(
        r#"
        sub     sp, sp, #12
        stmib   sp, {{r2, r3}}
        vmov    d0, r0, r1
        add     r0, sp, #4
        vldr    d1, [sp, #4]
        add     r0, r0, #15
        bic     r0, r0, #7
        vadd.f64        d0, d0, d1
        add     r1, r0, #8
        str     r1, [sp]
        vldr    d1, [r0]
        vadd.f64        d0, d0, d1
        vmov    r0, r1, d0
        add     sp, sp, #12
        bx      lr
    "#,
    )
}

Accepted ABIs

The set of accepted ABIs is the same as for c-variadic foreign functions, defined as rule items.extern.variadic.conventions:

• "aapcs"
• "C"
• "cdecl"
• "efiapi"
• "system"
• "sysv64"
• "win64"

And their corresponding -unwind variants. Given that naked functions desugar to a block of module assembly and a foreign definition, it makes sense to support the same set as source-level foreign definitions.

For c-variadic definitions we only accept "C" and "C-unwind".

Multiple c-variadic ABIs in the same program

LLVM supports c-variadic calls of different ABIs in the same program. We test both an arm and x86 configuration

• https://github.com/rust-lang/rust/blob/771916f9028e7fe56d2685f2c4f698de5d7d6a45/tests/ui/c-variadic/same-program-multiple-abis-arm.rs
• https://github.com/rust-lang/rust/blob/771916f9028e7fe56d2685f2c4f698de5d7d6a45/tests/ui/c-variadic/same-program-multiple-abis-x86_64.rs

Note that GCC, Clang and LLVM do not support c-variadic definitions of multiple ABIs: the va_start, va_arg etc. macros are always expanded using the default C calling convention. Clang and GCC reject a variable argument list on definitions that use a non-default calling convention.

History

• #t-lang > C-variadic naked functions
• implement feature(c_variadic_naked_functions) #148770

The stabilization report of feature(c_variadic) mentions this feature:

• Stabilize c-variadic function definitions #155697

Unresolved questions

None.

[folkertdev]

in the reference we now have to differentiate between naked and non-naked (clothed?) definitions. I guess we'll figure out some terminology in the reference PR.

View changes since the review

[folkertdev]

The reference PR for c-variadic is still in flight, but it would be neat if c_variadic_naked_functions could be stabilized in the same release. For the reference I don't think much is needed, maybe something like

r[items.fn.c-variadic.abi]
Only `extern "C"` and `extern "C-unwind"` function definitions can accept a variable argument list.

```rust,compile_fail
unsafe fn f(ap: ...) {} // ERROR: Not supported.
```

```rust,compile_fail
unsafe extern "sysv64" fn f(ap: ...) {} // ERROR: Not supported.
```

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

[rustbot]

r? @tiif

rustbot has assigned @tiif.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 74 candidates
• Random selection from 15 candidates

[traviscross]

Thanks @folkertdev.

@rfcbot fcp merge lang

[rust-rfcbot]

@traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[tmandry]

@rfcbot reviewed

[rust-rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[tiif]

Thanks! r=me once fcp ended.

View changes since this review

[rust-rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

[folkertdev]

I think it would make sense to stabilize this feature in the same release that stabilizes c-variadic definitions, 1.99.0. The cutoff for that is close though.

The only remaining blocker is an accepted reference PR. I think it makes sense to have this ride along on the existing one for c-variadic definitions. Is that OK?

We can of course request a beta-backport if this doesn't quite make it in before the cutoff.

[folkertdev]

Now that we have an approved reference PR

@bors r=tiif

[rust-bors]

📌 Commit 6a8ef66 has been approved by tiif

It is now in the queue for this repository.