-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Revisit work on cvoid #1086
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revisit work on cvoid #1086
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
The use of |
Thanks for the PR! I would not personally recommend this sort of feature detection though, there's precisely one right answer we know ahead of time for "when is Executing |
Okay, I've dropped the first commit with the feature detection. Do you think the de-duplication bit is still worth merging, or should I close this? |
@bors: r+ Nah that's fine, looks good to me! |
📌 Commit 90d8614 has been approved by |
Revisit work on cvoid At the recommendation of @SimonSapin [here](rust-lang/rust#53856 (comment)), I have revisited the build script to check whether `core::ffi::c_void` resolves, instead of relying on a particular `rustc` version. This allows use on `1.30.x` builds with `core::ffi::c_void`. I also noticed that `c_void` is defined twice in this crate, once in `lib.rs` and again in `switch.rs`. This instead defines `c_void` for every target except `wasm32`. As far as I can tell, this shouldn't actually change functionality on any existing targets.
💥 Test timed out |
@bors: retry |
Revisit work on cvoid At the recommendation of @SimonSapin [here](rust-lang/rust#53856 (comment)), I have revisited the build script to check whether `core::ffi::c_void` resolves, instead of relying on a particular `rustc` version. This allows use on `1.30.x` builds with `core::ffi::c_void`. I also noticed that `c_void` is defined twice in this crate, once in `lib.rs` and again in `switch.rs`. This instead defines `c_void` for every target except `wasm32`. As far as I can tell, this shouldn't actually change functionality on any existing targets.
☀️ Test successful - status-appveyor, status-travis |
At the recommendation of @SimonSapin here, I have revisited the build script to check whether
core::ffi::c_void
resolves, instead of relying on a particularrustc
version. This allows use on1.30.x
builds withcore::ffi::c_void
.I also noticed that
c_void
is defined twice in this crate, once inlib.rs
and again inswitch.rs
. This instead definesc_void
for every target exceptwasm32
. As far as I can tell, this shouldn't actually change functionality on any existing targets.