nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2024-11-01 23:12:02 +00:00
Code Issues Packages Projects Releases Wiki Activity

add 'import functions' to the list of situations where ABI compatibility comes up

Browse Source
This commit is contained in:
Ralf Jung 2023-11-10 20:33:09 +01:00
parent 281d8cc4ae
commit 044d05769b
1 changed files with 8 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
library/core/src/primitive_docs.rs
View File

@ -1515,11 +1515,14 @@ mod prim_ref {}
/// alignment, they might be passed in different registers and hence not be ABI-compatible.
///
/// ABI compatibility as a concern only arises in code that alters the type of function pointers,
/// and in code that combines `#[target_feature]` with `extern fn`. Altering the type of
/// function pointers is wildly unsafe (as in, a lot more unsafe than even
/// [`transmute_copy`][mem::transmute_copy]), and should only occur in the most exceptional
/// circumstances. `#[target_feature]` is also used rarely. But assuming such circumstances, what
/// are the rules?
/// code that imports functions via `extern` blocks, and in code that combines `#[target_feature]`
/// with `extern fn`. Altering the type of function pointers is wildly unsafe (as in, a lot more
/// unsafe than even [`transmute_copy`][mem::transmute_copy]), and should only occur in the most
/// exceptional circumstances. Most Rust code just imports functions via `use`. `#[target_feature]`
/// is also used rarely. So, most likely you do not have to worry about ABI compatibility.
///
/// But assuming such circumstances, what are the rules? For this section, we are specifically
/// concerned with the case where both the caller and the callee are defined in Rust.
///
/// For two signatures to be considered *ABI-compatible*, they must use a compatible ABI string,
/// must take the same number of arguments, the individual argument types and the return types must