RFC: Deprecate type aliases in std::os::*::raw #1415
Conversation
Deprecate type aliases and structs in `std::os::$platform::raw` in favor of trait-based accessors which return Rust types rather than the equivalent C type aliases.
alexcrichton
added
the
T-libs-api
| platform specific modules. All type aliases can be switched over to `u64` and | ||
| the `stat` structure could simply be redefined to `stat64` on Linux (minus | ||
| keeping the same name). This would, however, explicitly mean that | ||
| **std::os::raw is no longer FFI compatible with C**. |
There was a problem hiding this comment.
Right, but as your motivation says, the current FFI compatibility is a bit of an illusion anyway, thanks to LFS -DFILE_OFFSET_BITS.
There was a problem hiding this comment.
Yeah that's a good point! There's sort of a case to be made with "well they're FFI compatible if you pass no flags to the compiler", but that's shaky at best at this point.
|
🔔 This RFC is now entering its week-long final comment period 🔔 |
alexcrichton
added
the
final-comment-period
|
The libs team discussed this today and the conclusion was that there is not a clear enough path moving forward that doesn't involve theoretical breakage. We decided to leave this in FCP while I gather some statistics and flesh out a more concrete plan. |
|
Ok, I've done some analysis of what this change might have. The numbers here were gathered against these changes to the standard library, which I believe fully implement this RFC (enabling us to move to LFS on Linux at the same time). A crater report reports four regressions, three of which were spurious. I have submitted a PR for the other regression. Specifically, this regression involved code that looked like: libc::foo(..., value as std::os::raw::off_t)In other words, the regression came from the reliance that the types in std agreed with those in libc, which this RFC would be breaking. I then compiled Servo against a standard library with the patches above applied. With the Finally, I did a manual survey of all code on crates.io for usage of
The following usage was all observed but would not break from the change in this RFC (confirmed from the crater run)
My conclusion from this is that we can likely take the path set forth in this RFC (aka merge the two commits above at the same time). In summary, they:
The breaking changes are specifically breaking if you assume std/libc or std/gcc agree on the types, which from the above analysis looks like is limited to just a few crates (both of which have PRs to be updated). |
|
We discussed this during libs team triage today, and the conclusion was that given the limited fall out we should push forward with this. Thanks again for the discussion everyone! |
|
🎉 |
This commit is an implementation of [RFC 1415][rfc] which deprecates all types in the `std::os::*::raw` modules. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md Many of the types in these modules don't actually have a canonical platform representation, for example the definition of `stat` on 32-bit Linux will change depending on whether C code is compiled with LFS support or not. Unfortunately the current types in `std::os::*::raw` are billed as "compatible with C", which in light of this means it isn't really possible. To make matters worse, platforms like Android sometimes define these types as *smaller* than the way they're actually represented in the `stat` structure itself. This means that when methods like `DirEntry::ino` are called on Android the result may be truncated as we're tied to returning a `ino_t` type, not the underlying type. The commit here incorporates two backwards-compatible components: * Deprecate all `raw` types that aren't in `std::os::raw` * Expand the `std::os::*::fs::MetadataExt` trait on all platforms for method accessors of all fields. The fields now returned widened types which are the same across platforms (consistency across platforms is not required, however, it's just convenient). and two also backwards-incompatible components: * Change the definition of all `std::os::*::raw` type aliases to correspond to the newly widened types that are being returned on each platform. * Change the definition of `std::os::*::raw::stat` on Linux to match the LFS definitions rather than the standard ones. The breaking changes here will specifically break code that assumes that `libc` and `std` agree on the definition of `std::os::*::raw` types, or that the `std` types are faithful representations of the types in C. An [audit] has been performed of crates.io to determine the fallout which was determined two be minimal, with the two found cases of breakage having been fixed now. [audit]: rust-lang/rfcs#1415 (comment) --- Ok, so after all that, we're finally able to support LFS on Linux! This commit then simultaneously starts using `stat64` and friends on Linux to ensure that we can open >4GB files on 32-bit Linux. Yay! Closes rust-lang#28978 Closes rust-lang#30050 Closes rust-lang#31549
This commit is an implementation of [RFC 1415][rfc] which deprecates all types in the `std::os::*::raw` modules. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md Many of the types in these modules don't actually have a canonical platform representation, for example the definition of `stat` on 32-bit Linux will change depending on whether C code is compiled with LFS support or not. Unfortunately the current types in `std::os::*::raw` are billed as "compatible with C", which in light of this means it isn't really possible. To make matters worse, platforms like Android sometimes define these types as *smaller* than the way they're actually represented in the `stat` structure itself. This means that when methods like `DirEntry::ino` are called on Android the result may be truncated as we're tied to returning a `ino_t` type, not the underlying type. The commit here incorporates two backwards-compatible components: * Deprecate all `raw` types that aren't in `std::os::raw` * Expand the `std::os::*::fs::MetadataExt` trait on all platforms for method accessors of all fields. The fields now returned widened types which are the same across platforms (consistency across platforms is not required, however, it's just convenient). and two also backwards-incompatible components: * Change the definition of all `std::os::*::raw` type aliases to correspond to the newly widened types that are being returned on each platform. * Change the definition of `std::os::*::raw::stat` on Linux to match the LFS definitions rather than the standard ones. The breaking changes here will specifically break code that assumes that `libc` and `std` agree on the definition of `std::os::*::raw` types, or that the `std` types are faithful representations of the types in C. An [audit] has been performed of crates.io to determine the fallout which was determined two be minimal, with the two found cases of breakage having been fixed now. [audit]: rust-lang/rfcs#1415 (comment) --- Ok, so after all that, we're finally able to support LFS on Linux! This commit then simultaneously starts using `stat64` and friends on Linux to ensure that we can open >4GB files on 32-bit Linux. Yay! Closes #28978 Closes #30050 Closes #31549
Centril
added
A-repr
|
I’m not sure what’s the procedure for this but, is it possible to plan to remove/forbid calling e.g. I messed around with the code to be able to use |
|
The standard library cannot change in this way between editions; we can deprecate things but not remove them.
… On Oct 3, 2019, at 7:19 PM, Mélanie Chauvel (ariasuni) ***@***.***> wrote:
I’m not sure what’s the procedure for this but, is it possible to plan to remove/forbid calling e.g. MetadataExt::as_raw_stat() in a future edition?
I messed around with the code to be able to use statx (to get creation time on Linux) instead of stat64 but I’m stuck because of this API…
rust-lang/rust#61386
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Deprecate type aliases and structs in
std::os::$platform::rawin favor oftrait-based accessors which return Rust types rather than the equivalent C type
aliases.