fix aapcs ABI docs, and state where which ABIs are available #1948
Conversation
|
Is there somewhere in the compiler that we can easily see these defaults? My understanding is that if the ABI is not specified, the default is always Is aapcs the default for softfloat arm32? |
Correct. And "C" can be identical to other ABIs depending on the target. This PR documents my understanding of these equivalences. Cc @workingjubilee @Amanieu for people that know more about the nitty-gritty details. Basically,
I would think so but I don't know. |
Yes, "C" == "aapcs" on soft-float arm32. |
|
So if I am understanding correctly, the only way to determine what the behavior of the "C" calling convention is to dig through LLVM source, and each target seems to implement it differently, is that correct? For example aarch32/aarch64 use a method called I'm not entirely clear for stdcall, it says "default for the Win32 API". Why does it explicitly say "API"? Is this saying, this is the default that Microsoft uses for the Win32 API functions but is not the default of "C". That is, on i686-pc-windows-msvc, "C" is different from "stdcall"? Is that correct? "thiscall" is also confusing, as it uses the term "default" for "C++ member functions". So it's not the default for the "C" calling convention? (I'm finding the wording of "default" here confusing, so I'm trying to get clarity here.) |
Yes, that is correct. The default for win32 in general ("C" on that target) is "cdecl".
Yeah that's fair. I went for a most minimal edit here to correct some wrong information. This section could probably use a larger rewrite, but I'm not sure if/when I will have the time for that. |
This specifies the restrictions on which targets specific ABIs are available. These are defined in `rustc` in [`is_abi_supported`](https://github.com/rust-lang/rust/blob/eec6bd9d69832f57341c6de6a93fa7b9f47e2111/compiler/rustc_target/src/spec/mod.rs#L2610-L2613) and the associated `AbiMap`. Some of these are currently only implemented as future-incompatible warnings via `unsupported_calling_conventions`. I'm fine with just not acknowledging that, and saying what the intent is. This is split off from rust-lang#1948 with the intent of separating out the changes.
This specifies the restrictions on which target-specific ABIs are available. These are defined in `rustc` in [`is_abi_supported`] and the associated `AbiMap`. Some of these are currently only implemented as future incompatibly warnings via `unsupported_calling_conventions`. I'm fine with just not acknowledging that and saying what the intent is. This is split off from rust-lang#1948 with the intent of separating out the changes. [`is_abi_supported`]: https://github.com/rust-lang/rust/blob/eec6bd9d69832f57341c6de6a93fa7b9f47e2111/compiler/rustc_target/src/spec/mod.rs#L2610-L2613 Edited-by: TC
|
☔ The latest upstream changes (possibly 0275c80) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Looks like #2000 now landed almost everything I wrote here, except that the reference now still says that "aapcs" is the "default for ARM" which is not correct. |
|
Closing in favor of #2003. |
Fixes #1946.
Regarding ABI availability, this documents a post-rust-lang/rust#137018 world. Some of the combinations documented as "not available" here actually do get accepted but trigger a future-compat warning.