Re-export core::ffi::c_void if it exists #1082
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
Thanks! The |
IsaacWoods
force-pushed
the
core_cvoid
branch
from
e0fc704 to
14c8a81
Compare
IsaacWoods
force-pushed
the
core_cvoid
branch
from
14c8a81 to
79c80c4
Compare
|
Done :) I think the one Travis failure ( |
|
@bors: r+ |
|
📌 Commit 79c80c4 has been approved by |
Re-export core::ffi::c_void if it exists This is the second part of the implementation of [RFC 2521](rust-lang/rfcs#2521), replacing the definition of `c_void` in libc with a re-export of the type from `core::ffi::c_void` on builds it exists for. This uses the re-export for rustc version `1.31.0` or greater, as `1.30.x` was the current nightly when [the PR for the changes to libcore and libstd](rust-lang/rust#53910) was merged, so I'm assuming the first nightly they will appear in will be `1.31.0`; is this acceptable? cc rust-lang/rust#53856
|
☀️ Test successful - status-appveyor, status-travis |
This is the second part of the implementation of RFC 2521, replacing the definition of
c_voidin libc with a re-export of the type fromcore::ffi::c_voidon builds it exists for.This uses the re-export for rustc version
1.31.0or greater, as1.30.xwas the current nightly when the PR for the changes to libcore and libstd was merged, so I'm assuming the first nightly they will appear in will be1.31.0; is this acceptable?cc rust-lang/rust#53856