This commit applies rustfmt with default settings to files in
src/libcore *that are not involved in any currently open PR* to minimize
merge conflicts. The list of files involved in open PRs was determined
by querying GitHub's GraphQL API with this script:
https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8
With the list of files from the script in `outstanding_files`, the
relevant commands were:
$ find src/libcore -name '*.rs' | xargs rustfmt --edition=2018
$ rg libcore outstanding_files | xargs git checkout --
Repeating this process several months apart should get us coverage of
most of the rest of libcore.
- Compatible with Emscripten 1.38.46-upstream or later upstream.
- Refactors the Emscripten target spec to share code with other wasm
targets.
- Replaces the old incorrect wasm32 C call ABI with the correct one,
preserving the old one as wasm32_bindgen_compat for wasm-bindgen
compatibility.
- Updates the varargs ABI used by Emscripten and deletes the old one.
- Removes the obsolete wasm32-experimental-emscripten target.
- Uses EMCC_CFLAGS on CI to avoid the timeout problems with #63649.
- Refactors the Emscripten target spec to share code with other wasm
targets.
- Replaces the incorrect wasm32 C call ABI with the old asmjs
version, which is correct for both wasm32 and JS.
- Updates the varargs ABI used by Emscripten and deletes the old one.
- Removes the obsolete wasm32-experimental-emscripten target.
- Temporarily makes Emscripten targets use panic=abort by default
because supporting unwinding will require an LLVM patch.
Remove confusing comment about ideally using `!` for `c_void`
Using `!` for `c_void` would have the problem that pointers and
potentially references to an uninhabited type would be created, and at
least for references this is UB.
In addition document that newtype wrappers around `c_void` can be used
safely in place of `extern type` until the latter is stabilized.
----
I'm not 100% sure about the usage for opaque types as the [nomicon](https://doc.rust-lang.org/nomicon/ffi.html#representing-opaque-structs) still recommends using `#[repr(C)] pub struct Foo { _private: [u8; 0] }` but it seems like these two should be equivalent in the end? Also the `#[repr(C)]` (in both cases) should be unneeded because such types never being passed by value, never being dereferenced but only passed around as pointer or reference, so the representation of (*values* of) the type itself should not matter at all?
Also in context of `c_void` and `!` the second unresolved question in the [`extern type`](https://github.com/rust-lang/rust/issues/43467) stabilization ticket seems relevant
> In [std's](164619a8cf/src/libstd/os/raw.rs (L59-L64)) source, it is mentioned that LLVM expects i8* for C's void*.
> We'd need to continue to hack this for the two c_voids in std and libc.
> But perhaps this should be done across-the-board for all extern types?
> Somebody should check what Clang does.
Please correct me if my understanding is wrong and everything's actually fine as is.
We need at least two variants of the enum as otherwise the compiler
complains about the #[repr(u8)] attribute and we also need at least one
variant as otherwise the enum would be uninhabitated and dereferencing
pointers to it would be UB.
As such, mark the variants not unstable because they should not actually
exist but because they are temporary implementation details until
`extern type` is stable and can be used instead.
Using `!` for `c_void` would have the problem that pointers and
potentially references to an uninhabited type would be created, and at
least for references this is UB.
Also document in addition that newtype wrappers around `c_void` are not
recommended for representing opaque types (as a workaround for `extern
type` not being stable) but instead refer to the Nomicon.
* Update bootstrap compiler
* Update version to 1.33.0
* Remove some `#[cfg(stage0)]` annotations
Actually updating the version number is blocked on updating Cargo
codegen: Fix va_list - aarch64 iOS/Windows
## Summary
Fix code generated for `VaList` on Aarch64 iOS/Windows.
## Details
According to the [Apple - ARM64 Function Calling Conventions]:
> ... the type va_list is an alias for char * rather than for the struct
> type specified in the generic PCS.
The current implementation uses the generic Aarch64 structure for `VaList`
for Aarch64 iOS. Switch to using the `char *` variant of the `VaList`
and use the corresponding `emit_ptr_va_arg` for the `va_arg` intrinsic.
Windows always uses the `char *` variant of the `VaList`. Update the `va_arg`
intrinsic to use `emit_ptr_va_arg`.
[Apple - ARM64 Function Calling Conventions]: https://developer.apple.com/library/archive/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html
According to the Apple developer docs:
> The type va_list is an alias for char * rather than for the struct
> type specified in the generic PCS.
The current implementation uses the generic Aarch64 structure for VaList
for Aarch64 iOS.
Windows always uses the char * variant of the va_list.
