Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

std: Stabilize portions of std::os::$platform #23353

Merged
merged 1 commit into from
Mar 15, 2015

Conversation

alexcrichton
Copy link
Member

This commit starts to organize the std::os::$platform modules and in the
process stabilizes some of the functionality contained within. The organization
of these modules will reflect the organization of the standard library itself
with extension traits for primitives in the same corresponding module.

The OS-specific modules will grow more functionality over time including
concrete types that are not extending functionality of other structures, and
these will either go into the closest module in std::os::$platform or they
will grow a new module in the hierarchy.

The following items are now stable:

  • os::{unix, windows}
  • unix::ffi
  • unix::ffi::OsStrExt
  • unix::ffi::OsStrExt::{from_bytes, as_bytes, to_cstring}
  • unix::ffi::OsString
  • unix::ffi::OsStringExt::{from_vec, into_vec}
  • unix::process
  • unix::process::CommandExt
  • unix::process::CommandExt::{uid, gid}
  • unix::process::ExitStatusExt
  • unix::process::ExitStatusExt::signal
  • unix::prelude
  • windows::ffi
  • windows::ffi::OsStringExt
  • windows::ffi::OsStringExt::from_wide
  • windows::ffi::OsStrExt
  • windows::ffi::OsStrExt::encode_wide
  • windows::prelude

The following items remain unstable:

  • unix::io
  • unix::io::{Fd, AsRawFd}
  • unix::fs::{PermissionsExt, OpenOptionsExt}
  • windows::io
  • windows::io::{Handle, AsRawHandle}
  • windows::io::{Socket, AsRawSocket}
  • windows::fs
  • windows::fs::OpenOptionsExt

Due to the reorgnization of the platform extension modules, this commit is a
breaking change. Most imports can be fixed by adding the relevant libstd module
in the use path (such as ffi or fs).

[breaking-change]

@rust-highfive
Copy link
Collaborator

r? @pcwalton

(rust_highfive has picked a reviewer for you, use r? to override)

@alexcrichton
Copy link
Member Author

r? @aturon

I'll also note that the whitespace-ignoring view for this PR may be more helpful

@rust-highfive rust-highfive assigned aturon and unassigned pcwalton Mar 14, 2015
@huonw huonw mentioned this pull request Mar 14, 2015
10 tasks
@aturon aturon mentioned this pull request Mar 14, 2015
91 tasks
@aturon
Copy link
Member

aturon commented Mar 14, 2015

Exciting!

@bors: r+ 4c8d92b

@Manishearth
Copy link
Member

@bors: p=2

OS-specific, let's get this merged earlier so it doesn't block/break the next rollup

@bors
Copy link
Contributor

bors commented Mar 14, 2015

⌛ Testing commit 4c8d92b with merge 65ef39e...

@bors
Copy link
Contributor

bors commented Mar 14, 2015

💔 Test failed - auto-mac-64-opt

@Manishearth
Copy link
Member

/Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/src/libstd/os.rs:1708:17: 1708:34 error: unresolved import `os::unix::AsRawFd`. There is no `AsRawFd` in `sys::ext`
/Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/src/libstd/os.rs:1708             use os::unix::AsRawFd;
                                                                                                     ^~~~~~~~~~~~~~~~~
/Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/src/libstd/process.rs:576:13: 576:36 error: unresolved import `os::unix::ExitStatusExt`. There is no `ExitStatusExt` in `sys::ext`
/Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/src/libstd/process.rs:576         use os::unix::ExitStatusExt;
                                                                                                     ^~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to 2 previous errors
make: *** [x86_64-apple-darwin/stage2/test/stdtest-x86_64-apple-darwin] Error 101

@alexcrichton
Copy link
Member Author

@bors: r=aturon

@bors
Copy link
Contributor

bors commented Mar 15, 2015

@bors r=aturon e265e77

@bors
Copy link
Contributor

bors commented Mar 15, 2015

⌛ Testing commit e265e77 with merge adc9d7b...

bors added a commit that referenced this pull request Mar 15, 2015
This commit starts to organize the `std::os::$platform` modules and in the
process stabilizes some of the functionality contained within. The organization
of these modules will reflect the organization of the standard library itself
with extension traits for primitives in the same corresponding module.

The OS-specific modules will grow more functionality over time including
concrete types that are not extending functionality of other structures, and
these will either go into the closest module in `std::os::$platform` or they
will grow a new module in the hierarchy.

The following items are now stable:

* `os::{unix, windows}`
* `unix::ffi`
* `unix::ffi::OsStrExt`
* `unix::ffi::OsStrExt::{from_bytes, as_bytes, to_cstring}`
* `unix::ffi::OsString`
* `unix::ffi::OsStringExt::{from_vec, into_vec}`
* `unix::process`
* `unix::process::CommandExt`
* `unix::process::CommandExt::{uid, gid}`
* `unix::process::ExitStatusExt`
* `unix::process::ExitStatusExt::signal`
* `unix::prelude`
* `windows::ffi`
* `windows::ffi::OsStringExt`
* `windows::ffi::OsStringExt::from_wide`
* `windows::ffi::OsStrExt`
* `windows::ffi::OsStrExt::encode_wide`
* `windows::prelude`

The following items remain unstable:

* `unix::io`
* `unix::io::{Fd, AsRawFd}`
* `unix::fs::{PermissionsExt, OpenOptionsExt}`
* `windows::io`
* `windows::io::{Handle, AsRawHandle}`
* `windows::io::{Socket, AsRawSocket}`
* `windows::fs`
* `windows::fs::OpenOptionsExt`

Due to the reorgnization of the platform extension modules, this commit is a
breaking change. Most imports can be fixed by adding the relevant libstd module
in the `use` path (such as `ffi` or `fs`).

[breaking-change]
@bors
Copy link
Contributor

bors commented Mar 15, 2015

💔 Test failed - auto-mac-64-opt

This commit starts to organize the `std::os::$platform` modules and in the
process stabilizes some of the functionality contained within. The organization
of these modules will reflect the organization of the standard library itself
with extension traits for primitives in the same corresponding module.

The OS-specific modules will grow more functionality over time including
concrete types that are not extending functionality of other structures, and
these will either go into the closest module in `std::os::$platform` or they
will grow a new module in the hierarchy.

The following items are now stable:

* `os::{unix, windows}`
* `unix::ffi`
* `unix::ffi::OsStrExt`
* `unix::ffi::OsStrExt::{from_bytes, as_bytes, to_cstring}`
* `unix::ffi::OsString`
* `unix::ffi::OsStringExt::{from_vec, into_vec}`
* `unix::process`
* `unix::process::CommandExt`
* `unix::process::CommandExt::{uid, gid}`
* `unix::process::ExitStatusExt`
* `unix::process::ExitStatusExt::signal`
* `unix::prelude`
* `windows::ffi`
* `windows::ffi::OsStringExt`
* `windows::ffi::OsStringExt::from_wide`
* `windows::ffi::OsStrExt`
* `windows::ffi::OsStrExt::encode_wide`
* `windows::prelude`

The following items remain unstable:

* `unix::io`
* `unix::io::{Fd, AsRawFd}`
* `unix::fs::{PermissionsExt, OpenOptionsExt}`
* `windows::io`
* `windows::io::{Handle, AsRawHandle}`
* `windows::io::{Socket, AsRawSocket}`
* `windows::fs`
* `windows::fs::OpenOptionsExt`

Due to the reorgnization of the platform extension modules, this commit is a
breaking change. Most imports can be fixed by adding the relevant libstd module
in the `use` path (such as `ffi` or `fs`).

[breaking-change]
@alexcrichton
Copy link
Member Author

@bors: r=aturon 1f5f76a

@bors
Copy link
Contributor

bors commented Mar 15, 2015

⌛ Testing commit 1f5f76a with merge 542e2bb...

bors added a commit that referenced this pull request Mar 15, 2015
This commit starts to organize the `std::os::$platform` modules and in the
process stabilizes some of the functionality contained within. The organization
of these modules will reflect the organization of the standard library itself
with extension traits for primitives in the same corresponding module.

The OS-specific modules will grow more functionality over time including
concrete types that are not extending functionality of other structures, and
these will either go into the closest module in `std::os::$platform` or they
will grow a new module in the hierarchy.

The following items are now stable:

* `os::{unix, windows}`
* `unix::ffi`
* `unix::ffi::OsStrExt`
* `unix::ffi::OsStrExt::{from_bytes, as_bytes, to_cstring}`
* `unix::ffi::OsString`
* `unix::ffi::OsStringExt::{from_vec, into_vec}`
* `unix::process`
* `unix::process::CommandExt`
* `unix::process::CommandExt::{uid, gid}`
* `unix::process::ExitStatusExt`
* `unix::process::ExitStatusExt::signal`
* `unix::prelude`
* `windows::ffi`
* `windows::ffi::OsStringExt`
* `windows::ffi::OsStringExt::from_wide`
* `windows::ffi::OsStrExt`
* `windows::ffi::OsStrExt::encode_wide`
* `windows::prelude`

The following items remain unstable:

* `unix::io`
* `unix::io::{Fd, AsRawFd}`
* `unix::fs::{PermissionsExt, OpenOptionsExt}`
* `windows::io`
* `windows::io::{Handle, AsRawHandle}`
* `windows::io::{Socket, AsRawSocket}`
* `windows::fs`
* `windows::fs::OpenOptionsExt`

Due to the reorgnization of the platform extension modules, this commit is a
breaking change. Most imports can be fixed by adding the relevant libstd module
in the `use` path (such as `ffi` or `fs`).

[breaking-change]
@bors bors merged commit 1f5f76a into rust-lang:master Mar 15, 2015
@alexcrichton alexcrichton deleted the stabilize-os branch March 27, 2015 20:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants