Move std::os::raw to core::os::raw

[SimonSapin]

… and re-export at the old location.

This is primarily motivated by rust-lang/libc#71 (to support src/liblibc), but also because why not.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (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. 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.

[alexcrichton]

I've been wary of this in the past because although these are just type definitions it's tying libcore to C perhaps unnecessarily so. When working with libcore there's not really any notion of an OS as it should in theory only be dependent on the architecture it's being compiled for.

[SimonSapin]

it's tying libcore to C perhaps unnecessarily so

Everything in this module has it’s name prefixed with c_, and it doesn’t "infect" the rest of libcore. Systems written in Rust without C can choose not to use any of these types.

And some systems do FFI into C and also want to use #![no_std]. (For example, I believe https://github.com/briansmith/ring/ does the former and wants to do the latter eventually.)

[liigo]

Systems written in Rust without C can choose not to use any of these types.

Why not use extern crate libc or similar explicitly.

[SimonSapin]

With that argument, why does std::os::raw exist at all?

[alexcrichton]

Namespacing/putting in a module unfortunately doesn't reduce the connection between libcore and C to me at least. With these types we're somewhat semantically tying libcore to a C compiler and OS, e.g. making the two very difficult to separate (aka the absolute core library in Rust "kinda requires" C).

For example, there would no longer necessarily be a correct definition for libcore in various kernels here and there, these types would depend on what compiler you're using and what target that compiler itself has.

With that argument, why does std::os::raw exist at all?

The lowering traits in std::os::{unix, windows} return values which contain these types. If those didn't exist this module wouldn't exist.

[liigo]

libcore should be OS irrelevant, containing core::os{::raw} module makes no sense (implies the opposite). But libstd is always OS relevant, it's OK to has std::os.

[steveklabnik]

👍 @liigo , I think that line of reasoning makes a lot of sense.

[SimonSapin]

Fair enough. (And rust-lang/libc#71, which lead me to this, is not happening either anyway.)