@@ -99,35 +99,6 @@ cfg_if! {
9999 target_os = "watchos"
100100 ) )
101101 ) ) ] {
102- // This introduces partial support for FFI with __int128 and
103- // equivalent types on platforms where Rust's definition is validated
104- // to match the standard C ABI of that platform.
105- //
106- // Rust does not guarantee u128/i128 are sound for FFI, and its
107- // definitions are in fact known to be incompatible. [0]
108- //
109- // However these problems aren't fundamental, and are just platform
110- // inconsistencies. Specifically at the time of this writing:
111- //
112- // * For x64 SysV ABIs (everything but Windows), the types are underaligned.
113- // * For all Windows ABIs, Microsoft doesn't actually officially define __int128,
114- // and as a result different implementations don't actually agree on its ABI.
115- //
116- // But on the other major aarch64 platforms (android, linux, ios, macos) we have
117- // validated that rustc has the right ABI for these types. This is important because
118- // aarch64 uses these types in some fundamental OS types like user_fpsimd_struct,
119- // which represents saved simd registers.
120- //
121- // Any API which uses these types will need to `#[ignore(improper_ctypes)]`
122- // until the upstream rust issue is resolved, but this at least lets us make
123- // progress on platforms where this type is important.
124- //
125- // The list of supported architectures and OSes is intentionally very restricted,
126- // as careful work needs to be done to verify that a particular platform
127- // has a conformant ABI.
128- //
129- // [0]: https://github.com/rust-lang/rust/issues/54341
130-
131102 /// C `__int128` (a GCC extension that's part of many ABIs)
132103 pub type __int128 = i128 ;
133104 /// C `unsigned __int128` (a GCC extension that's part of many ABIs)
@@ -136,41 +107,6 @@ cfg_if! {
136107 pub type __int128_t = i128 ;
137108 /// C __uint128_t (alternate name for [__uint128][])
138109 pub type __uint128_t = u128 ;
139-
140- // NOTE: if you add more platforms to here, you may need to cfg
141- // these consts. They should always match the platform's values
142- // for `sizeof(__int128)` and `_Alignof(__int128)`.
143- const _SIZE_128: usize = 16 ;
144- const _ALIGN_128: usize = 16 ;
145-
146- // FIXME(ctest): ctest doesn't handle `_` as an identifier so these tests are temporarily
147- // disabled.
148- // macro_rules! static_assert_eq {
149- // ($a:expr, $b:expr) => {
150- // const _: [(); $a] = [(); $b];
151- // };
152- // }
153- //
154- // // Since Rust doesn't officially guarantee that these types
155- // // have compatible ABIs, we const assert that these values have the
156- // // known size/align of the target platform's libc. If rustc ever
157- // // tries to regress things, it will cause a compilation error.
158- // //
159- // // This isn't a bullet-proof solution because e.g. it doesn't
160- // // catch the fact that llvm and gcc disagree on how x64 __int128
161- // // is actually *passed* on the stack (clang underaligns it for
162- // // the same reason that rustc *never* properly aligns it).
163- // static_assert_eq!(size_of::<__int128>(), _SIZE_128);
164- // static_assert_eq!(align_of::<__int128>(), _ALIGN_128);
165-
166- // static_assert_eq!(size_of::<__uint128>(), _SIZE_128);
167- // static_assert_eq!(align_of::<__uint128>(), _ALIGN_128);
168-
169- // static_assert_eq!(size_of::<__int128_t>(), _SIZE_128);
170- // static_assert_eq!(align_of::<__int128_t>(), _ALIGN_128);
171-
172- // static_assert_eq!(size_of::<__uint128_t>(), _SIZE_128);
173- // static_assert_eq!(align_of::<__uint128_t>(), _ALIGN_128);
174110 } else if #[ cfg( all(
175111 target_arch = "aarch64" ,
176112 any(
0 commit comments