core-foundation-rs
core-foundation-rs copied to clipboard
servo
Trim dependencies
Of particular note:
libcis not needed in most cases, one can simply usestd::os::rawleaky-cowseems like it existed to work around compiler limitations, these are no more
@jrmuizel I've included version bumps in here as well, would be nice if you could also do a new release after this
Ping @jdm? This would be really nice to have in winit, I'd be able to remove a lot of old cruft from that
FWIW, it would be nice if the changes here moving everything towards using std wasn't applied universally. Notably, crates like core-foundation-sys and other -sys crates that contain nothing but bindings. These didn't strictly change much in this PR, but I wanted to bring up the idea since this seemed like a good place.
You stated this goal in the PR description:
libc is not needed in most cases, one can simply use std::os::raw
However, depending on the MSRV goals (if any) that these crates have, I would argue that using libc is the better option to make more of these available in no_std contexts to anyone who may want that. I personally found it surprising this weekend to find that core-foundation-sys used std given how little it does.
A lot of the C FFI types just moved to core in recent Rust versions that obsoletes the above, but it is probably too new for these crates given how widely used they are.
However, depending on the MSRV goals (if any) that these crates have, I would argue that using
libcis the better option to make more of these available inno_stdcontexts to anyone who may want that. I personally found it surprising this weekend to find thatcore-foundation-sysusedstdgiven how little it does.
@complexspaces What's the use case for using core-foundation-sys in a no-std environment?
What's the use case for using core-foundation-sys in a no-std environment?
@jrmuizel Binary sizes, primarily.
:umbrella: The latest upstream changes (presumably #548) made this pull request unmergeable. Please resolve the merge conflicts.
