Re-export c_void from std::os::raw

[SimonSapin]

This avoid silly errors like:

error: mismatched types:
 expected `*mut libc::c_void`,
    found `*mut std::os::raw::c_void`

and should have no other effect since the two definitions were identical.

CC servo/servo#8446

[SimonSapin]

Where I’m at it, should everything else from std::os::raw be re-exported as well? It’s less important for type aliases than custom enums, but in case they ever get out of sync again (rust-lang/rust#29867)

[alexcrichton]

The CI is failing here for the reason actually for why this was not done in the first place. I explained a bit more in #59 and this was also mentioned in the RFC, but for now this is intentional, so closing.

[SimonSapin]

This is causing so much pain :(

[SimonSapin]

I’ve been fighting with the same error all over the place for days:

 expected `*const std::os::raw::c_void`,
    found `*const libc::c_void`

[alexcrichton]

Can you elaborate on why that's coming up? That sounds like some dependencies started transitioning to using std's c_void while others are still using libc and they're getting mixed up?

[SimonSapin]

Yes, exactly. And this is happening across dozens of crates and repositories. Every time I update any dependency, I end up sending lots of PRs to fix precisely this error, sometimes by changing nothing but a version number in Cargo.toml.

[alexcrichton]

How does changing a version fix things? Both 0.1 and 0.2 define c_void, so I'm not sure how that'd get the types to align. Is that because some dependencies have updated to using the std c_void and older versions are using the libc c_void?

[SimonSapin]

For example, library A has a public function that takes a *const libc::c_void parameter and upgrades from libc 0.1 to 0.2. Library B depends on library A and calls that function with a pointer that comes from somewhere that still uses libc 0.1. In this case you’d get a build error that is fixed simply by changing a version number in B’s Cargo.toml. (Similar story with std::os::raw instead of libc 0.2) Repeat with dozens of libraries in a dense dependency graph.

It’s frustrating because the exact definition of c_void is as uninteresting as it gets. As far as I can tell, it could be pub type c_void = ();. Some projects do just that: PistonDevelopers/piston#1000, Rust-SDL2/rust-sdl2#465.

If c_void was a type alias like c_int with the same definition in three places, these build errors would not exist in the first place. But three identical enums are different types.

Anyway, now that libc 0.1 and 0.2 are as they are I don’t have a solution to propose that would help here. I’m mostly just ranting to vent frustration, sorry.

[SimonSapin]

@alexcrichton Are you still opposed to this? The reason you linked to above says “In order to have maximal compatibility with all Rust versions”. std::os::raw::c_void was stabilized in Rust 1.1.0. Is it time yet to let go of compatibility with Rust 1.0.0 ?

[alexcrichton]

Yes I would still be opposed to this. This doesn't make sense when libc's default mode of operation is no_std, which it should be.

The discussion about c_void specifically is broad and far reaching, I'd recommend reading https://internals.rust-lang.org/t/solve-std-os-raw-c-void/3268