core can't depend on external crates the way std can. Rather than revert
usage of cfg_if, add a copy of it to core. This does not export our
copy, even unstably; such a change could occur in a later commit.

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.

When CStr moves to core with an alias in std, this can link to
`crate::ffi::CStr`. However, linking in the reverse direction (from core
to std) requires a relative path, and that path can't work from both
core::ffi and std::os::raw (different number of `../` traversals
required).

bors added S-waiting-on-bors

and removed S-waiting-on-review

labels

bors added a commit to rust-lang-ci/rust that referenced this pull request

…askrgr

Rollup of 9 pull requests

Successful merges:

 - rust-lang#94464 (Suggest adding a new lifetime parameter when two elided lifetimes should match up for traits and impls.)
 - rust-lang#94476 (7 - Make more use of `let_chains`)
 - rust-lang#94478 (Fix panic when handling intra doc links generated from macro)
 - rust-lang#94482 (compiler: fix some typos)
 - rust-lang#94490 (Update books)
 - rust-lang#94496 (tests: accept llvm intrinsic in align-checking test)
 - rust-lang#94498 (9 - Make more use of `let_chains`)
 - rust-lang#94503 (Provide C FFI types via core::ffi, not just in std)
 - rust-lang#94513 (update Miri)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

This was referenced

3 tasks

48 tasks

57 tasks