@@ -99,35 +99,6 @@ cfg_if! {
99
99
target_os = "watchos"
100
100
) )
101
101
) ) ] {
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
-
131
102
/// C `__int128` (a GCC extension that's part of many ABIs)
132
103
pub type __int128 = i128 ;
133
104
/// C `unsigned __int128` (a GCC extension that's part of many ABIs)
@@ -136,41 +107,6 @@ cfg_if! {
136
107
pub type __int128_t = i128 ;
137
108
/// C __uint128_t (alternate name for [__uint128][])
138
109
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);
174
110
} else if #[ cfg( all(
175
111
target_arch = "aarch64" ,
176
112
any(
0 commit comments