Tracking Issue for core_ffi_c #94501

joshtriplett · 2022-03-01T22:11:10Z

Feature gate: #![feature(core_ffi_c)]

This is a tracking issue for providing the aliases for C types (c_int, c_char, etc) via core::ffi, not just via std::os::raw. The ability to interoperate with C code via FFI is not limited to crates using std; this allows using these types without std.

Public API

// core::ffi

pub type c_char = ...;
pub type c_short = ...;
pub type c_ushort = ...;
pub type c_int = ...;
pub type c_uint = ...;
// ...

The existing types in std::os::raw will become type aliases for the ones in core::ffi. This will use type aliases rather than re-exports, to allow the std types to remain stable while the core types are unstable.

This also moves the currently unstable NonZero variants and c_size_t/c_ssize_t/c_ptrdiff_t types to core::ffi, while leaving them unstable.

Steps / History

Implementation: Provide C FFI types via core::ffi, not just in std #94503
Final comment period (FCP)
Stabilization PR

The text was updated successfully, but these errors were encountered:

Provide C FFI types via core::ffi, not just in std Tracking issue: rust-lang#94501 The ability to interoperate with C code via FFI is not limited to crates using std; this allows using these types without std. The existing types in `std::os::raw` become type aliases for the ones in `core::ffi`. This uses type aliases rather than re-exports, to allow the std types to remain stable while the core types are unstable. This also moves the currently unstable `NonZero_` variants and `c_size_t`/`c_ssize_t`/`c_ptrdiff_t` types to `core::ffi`, while leaving them unstable. Historically, we didn't do this because these types are target-dependent. However, `core` itself is also target-dependent. `core` should not call any OS services, but it knows the target and the target's ABI.

bstrie · 2022-03-02T15:29:33Z

To clarify, was #94503 able to avoid insta-stability of the new items? There seems to be some confusion as to whether or not type aliases respect stability markers.

joshtriplett · 2022-03-03T01:56:26Z

@bstrie It appears so: core::ffi::c_ulong shows up as unstable, while std::os::raw::c_ulong shows up as stable.

madsmtm · 2022-06-07T16:16:33Z

The introductory docs for core currently says:

this library is platform-agnostic

So that should probably be modified slightly if we go with this change? (Which I am greatly in favour of btw)

SimonSapin · 2022-06-07T16:28:04Z

Should these items also be available in std::ffi, in order to keep std a superset of core? (Though in this case it’s redundant with std::os::raw)

joshtriplett · 2022-06-07T18:23:53Z

@SimonSapin They were, but that was reverted in 07ea143 because it caused breakage; we can re-add it as re-exports when we stabilize this.

joshtriplett · 2022-06-07T18:30:22Z

The introductory docs for core currently says:

this library is platform-agnostic

So that should probably be modified slightly if we go with this change? (Which I am greatly in favour of btw)

~~core is platform-agnostic: it's skeptical about platforms but doesn't deny their existence~~

More seriously: I think the key detail here is that core doesn't offer any interfaces to platform functionality; it doesn't call into the platform. I think offering portable types whose layout is platform-specific doesn't invalidate that. core also has interfaces which use usize, whose size varies by platform.

joshtriplett · 2022-06-12T21:16:07Z

Following up from Zulip:

@rust-lang/libs-api, shall we stabilize the core::ffi::c_* types?

@rfcbot merge

rfcbot · 2022-06-12T21:16:08Z

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

BurntSushi · 2022-06-13T12:51:57Z

To be clear, this also includes adding these types to std::ffi too?

joshtriplett · 2022-06-13T20:40:24Z

@BurntSushi Yes.

rfcbot · 2022-06-21T21:07:12Z

🔔 This is now entering its final comment period, as per the review above. 🔔

rfcbot · 2022-07-01T21:07:44Z

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

joshtriplett · 2022-07-16T21:48:15Z

Stabilized in #98315

Each `bindgen` release may upgrade the list of Rust targets. For instance, currently, in their master branch [1], the latest ones are: Nightly => { vectorcall_abi: #124485, ptr_metadata: #81513, layout_for_ptr: #69835, }, Stable_1_77(77) => { offset_of: #106655 }, Stable_1_73(73) => { thiscall_abi: #42202 }, Stable_1_71(71) => { c_unwind_abi: #106075 }, Stable_1_68(68) => { abi_efiapi: #105795 }, By default, the highest stable release in their list is used, and users are expected to set one if they need to support older Rust versions (e.g. see [2]). Thus, over time, new Rust features are used by default, and at some point, it is likely that `bindgen` will emit Rust code that requires a Rust version higher than our minimum (or perhaps enabling an unstable feature). Currently, there is no problem because the maximum they have, as seen above, is Rust 1.77.0, and our current minimum is Rust 1.78.0. Therefore, set a Rust target explicitly now to prevent going forward in time too much and thus getting potential build failures at some point. Since we also support a minimum `bindgen` version, and since `bindgen` does not support passing unknown Rust target versions, we need to use the list of our minimum `bindgen` version, rather than the latest. So, since `bindgen` 0.65.1 had this list [3], we need to use Rust 1.68.0: /// Rust stable 1.64 /// * `core_ffi_c` ([Tracking issue](rust-lang/rust#94501)) => Stable_1_64 => 1.64; /// Rust stable 1.68 /// * `abi_efiapi` calling convention ([Tracking issue](rust-lang/rust#65815)) => Stable_1_68 => 1.68; /// Nightly rust /// * `thiscall` calling convention ([Tracking issue](rust-lang/rust#42202)) /// * `vectorcall` calling convention (no tracking issue) /// * `c_unwind` calling convention ([Tracking issue](rust-lang/rust#74990)) => Nightly => nightly; ... /// Latest stable release of Rust pub const LATEST_STABLE_RUST: RustTarget = RustTarget::Stable_1_68; Thus add the `--rust-target 1.68` parameter. Add a comment as well explaining this. An alternative would be to use the currently running (i.e. actual) `rustc` and `bindgen` versions to pick a "better" Rust target version. However, that would introduce more moving parts depending on the user setup and is also more complex to implement. Cc: Christian Poveda <[email protected]> Cc: Emilio Cobos Álvarez <[email protected]> Link: https://github.com/rust-lang/rust-bindgen/blob/21c60f473f4e824d4aa9b2b508056320d474b110/bindgen/features.rs#L97-L105 [1] Link: rust-lang/rust-bindgen#2960 [2] Link: https://github.com/rust-lang/rust-bindgen/blob/7d243056d335fdc4537f7bca73c06d01aae24ddc/bindgen/features.rs#L131-L150 [3] Signed-off-by: Miguel Ojeda <[email protected]>

joshtriplett added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC labels Mar 1, 2022

joshtriplett mentioned this issue Mar 1, 2022

Provide C FFI types via core::ffi, not just in std #94503

Merged

bstrie mentioned this issue Mar 3, 2022

Port shim-sev to x86_64-unknown-none enarx/enarx#1462

Closed

This was referenced Mar 15, 2022

Expose c_int as core::ffi::c_int? rust-lang/rfcs#3012

Closed

refactor(shims): replace libc crate with vendored libc enarx/enarx#1537

Merged

bstrie mentioned this issue Apr 7, 2022

Compile with stable Rust enarx/enarx#1372

Open

12 tasks

This was referenced Jun 7, 2022

Move std::os::raw to libcore? #36193

Closed

Roadmap: move cty into the libc repo japaric/cty#14

Open

Unify std::os::raw::c_void and libc::c_void via libcore rust-lang/rfcs#2521

Merged

Types in std::os::raw should be same as libc crate #47027

Open

rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Jun 12, 2022

kkysen mentioned this issue Jun 17, 2022

Switch to core::ffi::c_* for C types instead of libc::c_* immunant/c2rust#297

Open

joshtriplett mentioned this issue Jun 20, 2022

Stabilize core::ffi:c_* and re-export in std::ffi #98315

Merged

rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Jun 21, 2022

ojeda mentioned this issue Jun 29, 2022

Rust unstable features needed for the kernel Rust-for-Linux/linux#2

Open

90 tasks

This was referenced Jun 29, 2022

Tracking Issue for #![feature(c_size_t)] (std::os::raw::c_size_t/std::os::raw::c_ssize_t) #88345

Open

Take advantage of feature(core_ffi_c) (and possibly feature(c_size_t)) rust-lang/rust-bindgen#2231

Closed

rfcbot added the finished-final-comment-period The final comment period is finished for this PR / Issue. label Jul 1, 2022

rfcbot added to-announce Announce this issue on triage meeting and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Jul 1, 2022

madsmtm mentioned this issue Jul 15, 2022

Issues in original projects madsmtm/objc2#22

Closed

80 tasks

joshtriplett closed this as completed Jul 16, 2022

madsmtm mentioned this issue Aug 11, 2022

Specify MSRV rust-windowing/raw-window-handle#101

Merged

apiraino removed the to-announce Announce this issue on triage meeting label Sep 8, 2022

bunnie mentioned this issue Nov 3, 2022

Use c2rust implementation when targeting Wasm betrusted-io/ring-xous#2

Merged

biryukovmaxim mentioned this issue Nov 27, 2022

Feature/support actix web shuttle-hq/shuttle#491

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking Issue for core_ffi_c #94501

Tracking Issue for core_ffi_c #94501

joshtriplett commented Mar 1, 2022 •

edited

Loading

bstrie commented Mar 2, 2022

joshtriplett commented Mar 3, 2022 •

edited

Loading

madsmtm commented Jun 7, 2022

SimonSapin commented Jun 7, 2022

joshtriplett commented Jun 7, 2022

joshtriplett commented Jun 7, 2022

joshtriplett commented Jun 12, 2022

rfcbot commented Jun 12, 2022 •

edited by m-ou-se

Loading

BurntSushi commented Jun 13, 2022

joshtriplett commented Jun 13, 2022

rfcbot commented Jun 21, 2022

rfcbot commented Jul 1, 2022

joshtriplett commented Jul 16, 2022

Tracking Issue for core_ffi_c #94501

Tracking Issue for core_ffi_c #94501

Comments

joshtriplett commented Mar 1, 2022 • edited Loading

Public API

Steps / History

bstrie commented Mar 2, 2022

joshtriplett commented Mar 3, 2022 • edited Loading

madsmtm commented Jun 7, 2022

SimonSapin commented Jun 7, 2022

joshtriplett commented Jun 7, 2022

joshtriplett commented Jun 7, 2022

joshtriplett commented Jun 12, 2022

rfcbot commented Jun 12, 2022 • edited by m-ou-se Loading

BurntSushi commented Jun 13, 2022

joshtriplett commented Jun 13, 2022

rfcbot commented Jun 21, 2022

rfcbot commented Jul 1, 2022

joshtriplett commented Jul 16, 2022

joshtriplett commented Mar 1, 2022 •

edited

Loading

joshtriplett commented Mar 3, 2022 •

edited

Loading

rfcbot commented Jun 12, 2022 •

edited by m-ou-se

Loading