Move WinAPI functions from libc to std::sys::windows::c

[retep998]

The functions were only being used from libstd anyway.
As for the external version that people might depend on, people can either not cargo update their libc or just transition to winapi.
No types or constants were moved in this phase.

r? @alexcrichton

[retep998]

Hmmm, it seems librustdoc::flock calls CreateFileW and CloseHandle. I'm going to see if I can rewrite it to use std::fs::File.

[retep998]

librustdoc::flock has been updated and the commit amended.

[alexcrichton]

This is definitely a breaking change to the crates.io libc crate which needs to be considered. We can signal this with a semver-incompatible version bump (e.g. moving to 0.2), but I would personally rather hold off on making these sorts of breaking changes until we have a more comprehensive design for liblibc. I think that "just removing all the function definitions" and not dealing with the types, for example, may not be the best way to approach this.

Could you elaborate on the rationale for this? I'm interested to hear what you think the long-term story for these bindings to be.

cc @rust-lang/libs

[retep998]

The rationale is that libc is not trying to be a wrapper to WinAPI. Most of the WinAPI in libc was added so that it could be used in Rust. Considering the current policy is to put new WinAPI in std::sys::windows::c rather than libc, it seemed like a good idea to clean out all the existing WinAPI from libc.

I'm not really sure how I envision libc's future since it is trying to be multiple things at once, like libc bindings and posix bindings, but neither is it attempting to include everything possible. The things in libc are a conglomerate of whatever was needed for Rust at some point in time, and are by no means comprehensive. For people who want posix and linux APIs there's things like nix, and for people who want WinAPI there is winapi.

I only did functions for now as more of a proof of concept to get feedback. I'd be happy to handle types and constants as well in this PR if doing everything at once is a better idea rather than splitting it up.

[nagisa]

IMO at least liblibc in its current form – trying to bind all platforms – should not exist at all and cargo should instead allow depending on different crates per-platform. I.e. you would depend on liblibc-gnu on GNU systems, liblibc-bsd on BSD, liblibc-apple on OS X, winapi packages on windows etc.

[sfackler]

It seems rather unfortunate to force any crate that wants to use well supported libc or POSIX functionality to explicitly enumerate all unixy systems in existence.

[nagisa]

@sfackler

[dependencies]
posix = "1.0"

which can then depend on whatever liblibc it wants and export posix APIs only. Anyway, liblibc is certainly not a place for winapi.

[alexcrichton]

I definitely agree that the design of liblibc needs to be re-thought, but I don't want to hastily go into a situation we're not prepared for. I think at this time we're not prepared for a sharding like @nagisa mentions, and I agree that this is leading towards that direction.

The alternative that I can think of is to continue the direction of liblibc being a "this is the system's API interface" kind of crate. There's definitely pros and cons in both directions, but it's something at least to consider.

[bors]

☔ The latest upstream changes (presumably #26601) made this pull request unmergeable. Please resolve the merge conflicts.

[alexcrichton]

I'm going to close this for now because it is a breaking change to liblibc and I'm not sure we're ready to commit to this path just yet. I suspect that a dive into redesigning liblibc will likely take this path, but for now it may be a bit premature to start moving everything around.