From 0cba7fb6f665300ba0febeff18f34cc74ff44224 Mon Sep 17 00:00:00 2001 From: Trevor Gross Date: Thu, 20 Feb 2025 05:46:52 +0000 Subject: Remove `i128` and `u128` from `improper_ctypes_definitions` Rust's 128-bit integers have historically been incompatible with C [1]. However, there have been a number of changes in Rust and LLVM that mean this is no longer the case: * Incorrect alignment of `i128` on x86 [1]: adjusting Rust's alignment proposed at https://github.com/rust-lang/compiler-team/issues/683, implemented at https://github.com/rust-lang/rust/pull/116672. * LLVM version of the above: resolved in LLVM, including ABI fix. Present in LLVM18 (our minimum supported version). * Incorrect alignment of `i128` on 64-bit PowerPC, SPARC, and MIPS [2]: Rust's data layouts adjusted at https://github.com/rust-lang/rust/pull/132422, https://github.com/rust-lang/rust/pull/132741, https://github.com/rust-lang/rust/pull/134115. * LLVM version of the above: done in LLVM 20 https://github.com/llvm/llvm-project/issues/102783. * Incorrect return convention of `i128` on Windows: adjusted to match GCC and Clang at https://github.com/rust-lang/rust/pull/134290. At [3], the lang team considered it acceptable to remove `i128` from `improper_ctypes_definitions` if the LLVM version is known to be compatible. Time has elapsed since then and we have dropped support for LLVM versions that do not have the x86 fixes, meaning a per-llvm-version lint should no longer be necessary. The PowerPC, SPARC, and MIPS changes only came in LLVM 20 but since Rust's datalayouts have also been updated to match, we will be using the correct alignment regardless of LLVM version. `repr(i128)` was added to this lint in [4], but is also removed here. Part of the decision is that `i128` should match `__int128` in C on platforms that provide it, which documentation is updated to indicate. We will not guarantee that `i128` matches `_BitInt(128)` since that can be different from `__int128`. Some platforms (usually 32-bit) do not provide `__int128`; if any ABIs are extended in the future to define it, we will need to make sure that our ABI matches. Closes: https://github.com/rust-lang/rust/issues/134288 Closes: https://github.com/rust-lang/rust/issues/128950 [1]: https://github.com/rust-lang/rust/issues/54341 [2]: https://github.com/rust-lang/rust/issues/128950 [3]: https://github.com/rust-lang/lang-team/issues/255#issuecomment-2088855084 [4]: https://github.com/rust-lang/rust/pull/138282 --- compiler/rustc_lint/messages.ftl | 2 -- compiler/rustc_lint/src/types.rs | 16 +--------------- 2 files changed, 1 insertion(+), 17 deletions(-) (limited to 'compiler') diff --git a/compiler/rustc_lint/messages.ftl b/compiler/rustc_lint/messages.ftl index 6913fa3e60b..c39ea4b04a3 100644 --- a/compiler/rustc_lint/messages.ftl +++ b/compiler/rustc_lint/messages.ftl @@ -374,8 +374,6 @@ lint_improper_ctypes = `extern` {$desc} uses type `{$ty}`, which is not FFI-safe .label = not FFI-safe .note = the type is defined here -lint_improper_ctypes_128bit = 128-bit integers don't currently have a known stable ABI - lint_improper_ctypes_array_help = consider passing a pointer to the array lint_improper_ctypes_array_reason = passing raw arrays by value is not FFI-safe diff --git a/compiler/rustc_lint/src/types.rs b/compiler/rustc_lint/src/types.rs index af134622d38..441ff02d579 100644 --- a/compiler/rustc_lint/src/types.rs +++ b/compiler/rustc_lint/src/types.rs @@ -1,9 +1,7 @@ use std::iter; use std::ops::ControlFlow; -use rustc_abi::{ - BackendRepr, Integer, IntegerType, TagEncoding, VariantIdx, Variants, WrappingRange, -}; +use rustc_abi::{BackendRepr, TagEncoding, VariantIdx, Variants, WrappingRange}; use rustc_data_structures::fx::FxHashSet; use rustc_errors::DiagMessage; use rustc_hir::intravisit::VisitorExt; @@ -1284,14 +1282,6 @@ impl<'a, 'tcx> ImproperCTypesVisitor<'a, 'tcx> { }; } - if let Some(IntegerType::Fixed(Integer::I128, _)) = def.repr().int { - return FfiUnsafe { - ty, - reason: fluent::lint_improper_ctypes_128bit, - help: None, - }; - } - use improper_ctypes::check_non_exhaustive_variant; let non_exhaustive = def.variant_list_has_applicable_non_exhaustive(); @@ -1324,10 +1314,6 @@ impl<'a, 'tcx> ImproperCTypesVisitor<'a, 'tcx> { // but only the base type is relevant for being representable in FFI. ty::Pat(base, ..) => self.check_type_for_ffi(acc, base), - ty::Int(ty::IntTy::I128) | ty::Uint(ty::UintTy::U128) => { - FfiUnsafe { ty, reason: fluent::lint_improper_ctypes_128bit, help: None } - } - // Primitive types with a stable representation. ty::Bool | ty::Int(..) | ty::Uint(..) | ty::Float(..) | ty::Never => FfiSafe, -- cgit 1.4.1-3-g733a5