Stabilize extended_varargs_abi_support

[Soveu]

I think that is everything? If there is any documentation regarding extern and/or varargs to correct, let me know, some quick greps suggest that there might be none.

Tracking issue: #100189

[rustbot]

r? @wesleywiser

(rustbot has picked a reviewer for you, use r? to override)

[Soveu]

@rustbot label F-extended_varargs_abi_support

[kadiwa4]

use CURRENT_RUSTC_VERSION instead of a version number here

[tgross35]

Tracking issue: #100189

[bors]

☔ The latest upstream changes (presumably #116550) made this pull request unmergeable. Please resolve the merge conflicts.

[Soveu]

@wesleywiser

[bors]

☔ The latest upstream changes (presumably #118823) made this pull request unmergeable. Please resolve the merge conflicts.

[apiraino]

r? compiler

[Nadrieril]

I'm on vacation for a few days :)
r? compiler

[cjgillot]

Not completely sure which team should be nominated for stabilization, so labeling both in doubt.

[pnkfelix]

Just to add on to @cjgillot 's comment above: @wesleywiser and I could not remember earlier today whether T-lang wants to own FCP'ing changes like this that are restricted to extending the set of calling-conventions (i.e. the conv in extern "conv" fn foo(...)), which is largely a detail about what platforms one is interoperating with, and not about changing the expressiveness of the Rust language as a whole in the abstract.

(My own gut reaction is that T-compiler is a more natural owner for this than T-lang, but I wasn't certain and so it seems best to let the nomination stand and let the two teams duke it out.)

[apiraino]

Removing the T-compiler nomination until after T-lang discussed this. Feel free to re-add T-compiler!

@rustbot label -I-compiler-nominated

[Soveu]

Question: Does this include -unwind variants for each of the ABIs or not?

Well, yes. I haven't thought about it initially (as I was mostly focused on efiapi, non-unwind win64 and sysv64), but currently Abi::supports_varargs looks like this:

    pub fn supports_varargs(self) -> bool {
        // * C and Cdecl obviously support varargs.
        // * C can be based on Aapcs, SysV64 or Win64, so they must support varargs.
        // * EfiApi is based on Win64 or C, so it also supports it.
        // * System falls back to C for functions with varargs.
        //
        // * Stdcall does not, because it would be impossible for the callee to clean
        //   up the arguments. (callee doesn't know how many arguments are there)
        // * Same for Fastcall, Vectorcall and Thiscall.
        // * Other calling conventions are related to hardware or the compiler itself.
        match self {
            Self::C { .. }
            | Self::Cdecl { .. }
            | Self::System { .. }
            | Self::Aapcs { .. }
            | Self::Win64 { .. }
            | Self::SysV64 { .. }
            | Self::EfiApi => true,
            _ => false,
        }
    }

So whether there is Abi::Win64 { unwind: true } or Abi::Win64 { unwind: false }, it should treat them the same.

Should I rebase the change or will there be some exceptions for -unwind calling conventions?

[Soveu]

Removing the T-compiler nomination until after T-lang discussed this. Feel free to re-add T-compiler!

@rustbot label -I-compiler-nominated

@rustbot label +I-compiler-nominated

[apiraino]

T-compiler looked again at this proposal during the triage meeting and is fine with it.

@rustbot label -I-compiler-nominated

[rustbot]

There are merge commits (commits with multiple parents) in your changes. We have a no merge policy so these commits will need to be removed for this pull request to be merged.

You can start a rebase with the following commands:

$ # rebase
$ git pull --rebase https://github.com/rust-lang/rust.git master
$ git push --force-with-lease

The following commits are merge commits:

• e936bbb

[Soveu]

lgtm :)
@rustbot label +S-waiting-on-review

[bors]

☔ The latest upstream changes (presumably #131448) made this pull request unmergeable. Please resolve the merge conflicts.

[Soveu]

uhh, I did not notice that I changed some submodules by accident

[bors]

☔ The latest upstream changes (presumably #132027) made this pull request unmergeable. Please resolve the merge conflicts.

[cjgillot]

r=me after rebase