Ramon de C Valle

Sorry if it's unclear. Let me try to summarize: LLVM uses type metadata to allow IR modules to aggregate pointers by their types. This type metadata is used by LLVM...

This is a requirement for cross-language LLVM CFI support, which is forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or...

Neither the current implementation nor what this RFC proposes introduces any constraints to the language (besides forward-edge control flow protection). The language already distinguishes between both its explicitly-sized integer types...

To enable CFI and cross-language CFI to work properly, the correct/corresponding C types would need to (and arguably should anyway) be used for extern "C" function declarations, as is explicitly...

> Or just > > ```rust > extern "C" { fn foo(x: c_int); } > … > foo(42i32); > ``` As long as the extern "C" function declaration continues having...

> That compiler change doesn't imply any user-facing changes, as the changes are for rustdoc support and getting more information, and rustdoc can run without doing codegen. So I don't...

> Oh and it's possible to use generics with FFI: > > ```rust > unsafe extern "C" fn callback(input: T, user_data: *mut c_void) {...} > > let user_data = &mut...

Let me provide some background information from the [design document](https://rcvalle.com/docs/rust-cfi-design-doc.pdf), so the costs (and the risks) vs benefits of the options that are being proposed may be fully understood: >...

> For example, would just an entirely new set of types be acceptable? Under a `core::ffi::cfi` sub-module perhaps? Then code that wants to opt in to CFI can clearly and...

r? @compiler-errors