Skip to content

Commit a998838

Browse files
ricci009ricci009
committed
temporary workaround against tidy errors
1 parent 6f74c06 commit a998838

File tree

2 files changed

+108
-106
lines changed

2 files changed

+108
-106
lines changed

‎library/core/src/ffi/mod.rs‎

Lines changed: 106 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -55,6 +55,112 @@ mod primitives;
5555
#[stable(feature = "core_ffi", since = "1.30.0")]
5656
pub use self::primitives::*;
5757

58+
mod c_char_definition {
59+
cfg_if! {
60+
// These are the targets on which c_char is unsigned. Usually the
61+
// signedness is the same for all target_os values on a given architecture
62+
// but there are some exceptions (see isSignedCharDefault() in clang).
63+
//
64+
// aarch64:
65+
// Section 10 "Arm C and C++ language mappings" in Procedure Call Standard for the Arm®
66+
// 64-bit Architecture (AArch64) says C/C++ char is unsigned byte.
67+
// https://github.com/ARM-software/abi-aa/blob/2024Q3/aapcs64/aapcs64.rst#arm-c-and-c-language-mappings
68+
// arm:
69+
// Section 8 "Arm C and C++ Language Mappings" in Procedure Call Standard for the Arm®
70+
// Architecture says C/C++ char is unsigned byte.
71+
// https://github.com/ARM-software/abi-aa/blob/2024Q3/aapcs32/aapcs32.rst#arm-c-and-c-language-mappings
72+
// csky:
73+
// Section 2.1.2 "Primary Data Type" in C-SKY V2 CPU Applications Binary Interface
74+
// Standards Manual says ANSI C char is unsigned byte.
75+
// https://github.com/c-sky/csky-doc/blob/9f7121f7d40970ba5cc0f15716da033db2bb9d07/C-SKY_V2_CPU_Applications_Binary_Interface_Standards_Manual.pdf
76+
// Note: this doesn't seem to match Clang's default (https://github.com/rust-lang/rust/issues/129945).
77+
// hexagon:
78+
// Section 3.1 "Basic data type" in Qualcomm Hexagon™ Application
79+
// Binary Interface User Guide says "By default, the `char` data type is unsigned."
80+
// https://docs.qualcomm.com/bundle/publicresource/80-N2040-23_REV_K_Qualcomm_Hexagon_Application_Binary_Interface_User_Guide.pdf
81+
// msp430:
82+
// Section 2.1 "Basic Types" in MSP430 Embedded Application Binary
83+
// Interface says "The char type is unsigned by default".
84+
// https://www.ti.com/lit/an/slaa534a/slaa534a.pdf
85+
// powerpc/powerpc64:
86+
// - PPC32 SysV: "Table 3-1 Scalar Types" in System V Application Binary Interface PowerPC
87+
// Processor Supplement says ANSI C char is unsigned byte
88+
// https://refspecs.linuxfoundation.org/elf/elfspec_ppc.pdf
89+
// - PPC64 ELFv1: Section 3.1.4 "Fundamental Types" in 64-bit PowerPC ELF Application
90+
// Binary Interface Supplement 1.9 says ANSI C is unsigned byte
91+
// https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUND-TYPE
92+
// - PPC64 ELFv2: Section 2.1.2.2 "Fundamental Types" in 64-Bit ELF V2 ABI Specification
93+
// says char is unsigned byte
94+
// https://openpowerfoundation.org/specifications/64bitelfabi/
95+
// - AIX: XL C for AIX Language Reference says "By default, char behaves like an unsigned char."
96+
// https://www.ibm.com/docs/en/xl-c-aix/13.1.3?topic=specifiers-character-types
97+
// riscv32/riscv64:
98+
// C/C++ type representations section in RISC-V Calling Conventions
99+
// page in RISC-V ELF psABI Document says "char is unsigned."
100+
// https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/draft-20240829-13bfa9f54634cb60d86b9b333e109f077805b4b3/riscv-cc.adoc#cc-type-representations
101+
// s390x:
102+
// - ELF: "Table 1.1.: Scalar types" in ELF Application Binary Interface s390x Supplement
103+
// Version 1.6.1 categorize ISO C char in unsigned integer
104+
// https://github.com/IBM/s390x-abi/releases/tag/v1.6.1
105+
// - z/OS: XL C/C++ Language Reference says: "By default, char behaves like an unsigned char."
106+
// https://www.ibm.com/docs/en/zos/3.1.0?topic=specifiers-character-types
107+
// xtensa:
108+
// Section 2.17.1 "Data Types and Alignment" of Xtensa LX Microprocessor Overview handbook
109+
// says "`char` type is unsigned by default".
110+
// https://loboris.eu/ESP32/Xtensa_lx%20Overview%20handbook.pdf
111+
//
112+
// On the following operating systems, c_char is signed by default, regardless of architecture.
113+
// Darwin (macOS, iOS, etc.):
114+
// Apple targets' c_char is signed by default even on arm
115+
// https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Handle-data-types-and-data-alignment-properly
116+
// Windows:
117+
// Windows MSVC C++ Language Reference says "Microsoft-specific: Variables of type char
118+
// are promoted to int as if from type signed char by default, unless the /J compilation
119+
// option is used."
120+
// https://learn.microsoft.com/en-us/cpp/cpp/fundamental-types-cpp?view=msvc-170#character-types
121+
// L4Re:
122+
// The kernel builds with -funsigned-char on all targets (but useserspace follows the
123+
// architecture defaults). As we only have a target for userspace apps so there are no
124+
// special cases for L4Re below.
125+
// https://github.com/rust-lang/rust/pull/132975#issuecomment-2484645240
126+
if #[cfg(all(
127+
not(windows),
128+
not(target_vendor = "apple"),
129+
any(
130+
target_arch = "aarch64",
131+
target_arch = "arm",
132+
target_arch = "csky",
133+
target_arch = "hexagon",
134+
target_arch = "msp430",
135+
target_arch = "powerpc",
136+
target_arch = "powerpc64",
137+
target_arch = "riscv32",
138+
target_arch = "riscv64",
139+
target_arch = "s390x",
140+
target_arch = "xtensa",
141+
)
142+
))] {
143+
pub(super) type c_char = u8;
144+
} else {
145+
// On every other target, c_char is signed.
146+
pub(super) type c_char = i8;
147+
}
148+
}
149+
}
150+
151+
mod c_long_definition {
152+
cfg_if! {
153+
if #[cfg(all(target_pointer_width = "64", not(windows)))] {
154+
pub(super) type c_long = i64;
155+
pub(super) type c_ulong = u64;
156+
} else {
157+
// The minimal size of `long` in the C standard is 32 bits
158+
pub(super) type c_long = i32;
159+
pub(super) type c_ulong = u32;
160+
}
161+
}
162+
}
163+
58164
// N.B., for LLVM to recognize the void pointer type and by extension
59165
// functions like malloc(), we need to have it represented as i8* in
60166
// LLVM bitcode. The enum used here ensures this and prevents misuse

‎library/core/src/ffi/primitives.rs‎

Lines changed: 2 additions & 106 deletions
Original file line numberDiff line numberDiff line change
@@ -8,6 +8,8 @@
88
//!
99
//! Contains only the primitive types, mod.rs contains additional types
1010
11+
#![stable(feature = "core_ffi", since = "1.30.0")]
12+
1113
type_alias! { "c_char.md", c_char = c_char_definition::c_char; #[doc(cfg(all()))] }
1214

1315
type_alias! { "c_schar.md", c_schar = i8; }
@@ -48,99 +50,6 @@ pub type c_ptrdiff_t = isize;
4850
#[unstable(feature = "c_size_t", issue = "88345")]
4951
pub type c_ssize_t = isize;
5052

51-
mod c_char_definition {
52-
cfg_if! {
53-
// These are the targets on which c_char is unsigned. Usually the
54-
// signedness is the same for all target_os values on a given architecture
55-
// but there are some exceptions (see isSignedCharDefault() in clang).
56-
//
57-
// aarch64:
58-
// Section 10 "Arm C and C++ language mappings" in Procedure Call Standard for the Arm®
59-
// 64-bit Architecture (AArch64) says C/C++ char is unsigned byte.
60-
// https://github.com/ARM-software/abi-aa/blob/2024Q3/aapcs64/aapcs64.rst#arm-c-and-c-language-mappings
61-
// arm:
62-
// Section 8 "Arm C and C++ Language Mappings" in Procedure Call Standard for the Arm®
63-
// Architecture says C/C++ char is unsigned byte.
64-
// https://github.com/ARM-software/abi-aa/blob/2024Q3/aapcs32/aapcs32.rst#arm-c-and-c-language-mappings
65-
// csky:
66-
// Section 2.1.2 "Primary Data Type" in C-SKY V2 CPU Applications Binary Interface
67-
// Standards Manual says ANSI C char is unsigned byte.
68-
// https://github.com/c-sky/csky-doc/blob/9f7121f7d40970ba5cc0f15716da033db2bb9d07/C-SKY_V2_CPU_Applications_Binary_Interface_Standards_Manual.pdf
69-
// Note: this doesn't seem to match Clang's default (https://github.com/rust-lang/rust/issues/129945).
70-
// hexagon:
71-
// Section 3.1 "Basic data type" in Qualcomm Hexagon™ Application
72-
// Binary Interface User Guide says "By default, the `char` data type is unsigned."
73-
// https://docs.qualcomm.com/bundle/publicresource/80-N2040-23_REV_K_Qualcomm_Hexagon_Application_Binary_Interface_User_Guide.pdf
74-
// msp430:
75-
// Section 2.1 "Basic Types" in MSP430 Embedded Application Binary
76-
// Interface says "The char type is unsigned by default".
77-
// https://www.ti.com/lit/an/slaa534a/slaa534a.pdf
78-
// powerpc/powerpc64:
79-
// - PPC32 SysV: "Table 3-1 Scalar Types" in System V Application Binary Interface PowerPC
80-
// Processor Supplement says ANSI C char is unsigned byte
81-
// https://refspecs.linuxfoundation.org/elf/elfspec_ppc.pdf
82-
// - PPC64 ELFv1: Section 3.1.4 "Fundamental Types" in 64-bit PowerPC ELF Application
83-
// Binary Interface Supplement 1.9 says ANSI C is unsigned byte
84-
// https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUND-TYPE
85-
// - PPC64 ELFv2: Section 2.1.2.2 "Fundamental Types" in 64-Bit ELF V2 ABI Specification
86-
// says char is unsigned byte
87-
// https://openpowerfoundation.org/specifications/64bitelfabi/
88-
// - AIX: XL C for AIX Language Reference says "By default, char behaves like an unsigned char."
89-
// https://www.ibm.com/docs/en/xl-c-aix/13.1.3?topic=specifiers-character-types
90-
// riscv32/riscv64:
91-
// C/C++ type representations section in RISC-V Calling Conventions
92-
// page in RISC-V ELF psABI Document says "char is unsigned."
93-
// https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/draft-20240829-13bfa9f54634cb60d86b9b333e109f077805b4b3/riscv-cc.adoc#cc-type-representations
94-
// s390x:
95-
// - ELF: "Table 1.1.: Scalar types" in ELF Application Binary Interface s390x Supplement
96-
// Version 1.6.1 categorize ISO C char in unsigned integer
97-
// https://github.com/IBM/s390x-abi/releases/tag/v1.6.1
98-
// - z/OS: XL C/C++ Language Reference says: "By default, char behaves like an unsigned char."
99-
// https://www.ibm.com/docs/en/zos/3.1.0?topic=specifiers-character-types
100-
// xtensa:
101-
// Section 2.17.1 "Data Types and Alignment" of Xtensa LX Microprocessor Overview handbook
102-
// says "`char` type is unsigned by default".
103-
// https://loboris.eu/ESP32/Xtensa_lx%20Overview%20handbook.pdf
104-
//
105-
// On the following operating systems, c_char is signed by default, regardless of architecture.
106-
// Darwin (macOS, iOS, etc.):
107-
// Apple targets' c_char is signed by default even on arm
108-
// https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Handle-data-types-and-data-alignment-properly
109-
// Windows:
110-
// Windows MSVC C++ Language Reference says "Microsoft-specific: Variables of type char
111-
// are promoted to int as if from type signed char by default, unless the /J compilation
112-
// option is used."
113-
// https://learn.microsoft.com/en-us/cpp/cpp/fundamental-types-cpp?view=msvc-170#character-types
114-
// L4Re:
115-
// The kernel builds with -funsigned-char on all targets (but useserspace follows the
116-
// architecture defaults). As we only have a target for userspace apps so there are no
117-
// special cases for L4Re below.
118-
// https://github.com/rust-lang/rust/pull/132975#issuecomment-2484645240
119-
if #[cfg(all(
120-
not(windows),
121-
not(target_vendor = "apple"),
122-
any(
123-
target_arch = "aarch64",
124-
target_arch = "arm",
125-
target_arch = "csky",
126-
target_arch = "hexagon",
127-
target_arch = "msp430",
128-
target_arch = "powerpc",
129-
target_arch = "powerpc64",
130-
target_arch = "riscv32",
131-
target_arch = "riscv64",
132-
target_arch = "s390x",
133-
target_arch = "xtensa",
134-
)
135-
))] {
136-
pub(super) type c_char = u8;
137-
} else {
138-
// On every other target, c_char is signed.
139-
pub(super) type c_char = i8;
140-
}
141-
}
142-
}
143-
14453
mod c_int_definition {
14554
cfg_if! {
14655
if #[cfg(any(target_arch = "avr", target_arch = "msp430"))] {
@@ -152,16 +61,3 @@ mod c_int_definition {
15261
}
15362
}
15463
}
155-
156-
mod c_long_definition {
157-
cfg_if! {
158-
if #[cfg(all(target_pointer_width = "64", not(windows)))] {
159-
pub(super) type c_long = i64;
160-
pub(super) type c_ulong = u64;
161-
} else {
162-
// The minimal size of `long` in the C standard is 32 bits
163-
pub(super) type c_long = i32;
164-
pub(super) type c_ulong = u32;
165-
}
166-
}
167-
}

0 commit comments

Comments
 (0)