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

Tracking Issue for restructuring std::sys #117276

Open
15 of 18 tasks
joboet opened this issue Oct 27, 2023 · 1 comment
Open
15 of 18 tasks

Tracking Issue for restructuring std::sys #117276

joboet opened this issue Oct 27, 2023 · 1 comment
Assignees
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC E-help-wanted Call for participation: Help is requested to fix this issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Comments

@joboet
Copy link
Member

joboet commented Oct 27, 2023

On Wednesday, the libs-team discussed reorganizing the platform-specific modules inside std, namely sys and sys_common into a new structure. These modules will be merged into one sys module with a feature-first organization:

  • the submodules of sys, named after the feature they implement, contain all the implementations of the different platforms and provide a uniform interface that the rest of std may depend on. E.g. sys::thread_local, sys::fs or sys::thread_parking.
  • sys::pal contains platform-specific generic API wrappers like FileDesc cvt (UNIX) used to implement these features. E.g. sys::pal::unix, sys::pal::windows or (perhaps) sys::pal::apple.

The rest of std, modulo std::os, should now only depend on sys::feature_name and not sys::pal. The implementations themselves may however depend on other parts of std as necessary.

Tasks

Preview Give feedback
  1. A-meta A-testsuite S-waiting-on-bors T-bootstrap T-compiler T-libs merged-by-bors
    ChrisDenton
  2. A-testsuite S-waiting-on-bors T-bootstrap T-libs
    ChrisDenton
  3. O-SGX O-hermit O-solid O-unix O-wasi O-wasm O-windows S-waiting-on-bors T-libs
    ChrisDenton
  4. O-SGX O-hermit O-solid O-unix O-wasi O-wasm O-windows S-waiting-on-bors T-libs
    ChrisDenton
  5. O-SGX O-hermit O-solid O-unix O-wasi O-wasm O-windows S-waiting-on-bors T-libs
    ChrisDenton
  6. A-meta O-SGX O-hermit O-solid O-unix O-wasi O-wasm O-windows S-waiting-on-bors T-libs merged-by-bors
    ChrisDenton
  7. S-waiting-on-bors T-libs
    ChrisDenton
  8. A-meta O-wasi O-wasm S-waiting-on-bors T-libs
    jhpratt
  9. S-waiting-on-bors T-libs
    jhpratt
  10. O-SGX O-unix O-wasi O-wasm O-windows S-waiting-on-bors T-libs
    ChrisDenton
  11. A-thread-locals O-SGX O-hermit O-itron O-solid O-unix O-wasi O-wasm O-windows S-waiting-on-bors T-libs merged-by-bors
    Mark-Simulacrum
  12. S-waiting-on-bors T-libs
    workingjubilee
  13. O-SGX O-hermit O-solid O-unix O-wasi O-wasm O-windows S-waiting-on-bors T-libs merged-by-bors
    cuviper
  14. O-SGX O-hermit O-solid O-unix O-wasi O-wasm O-windows S-waiting-on-bors T-libs
    Noratrieb
  15. O-SGX O-hermit O-solid O-unix O-wasi O-wasm O-windows S-waiting-on-bors T-libs
    ChrisDenton
  16. O-SGX O-hermit O-solid O-unix O-wasi O-wasm O-windows S-waiting-on-bors T-libs
    Amanieu
  17. O-SGX O-hermit O-solid O-unix O-wasi O-wasm O-windows S-waiting-on-review T-libs
    Mark-Simulacrum

@rustbot label +T-libs +E-help-wanted
@rustbot claim

@joboet joboet added the C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC label Oct 27, 2023
@rustbot rustbot added the T-libs Relevant to the library team, which will review and decide on the PR/issue. label Oct 27, 2023
bors added a commit to rust-lang-ci/rust that referenced this issue Jan 12, 2024
…sDenton

Move platform modules into `sys::pal`

This is the initial step of rust-lang#117276. `sys` just re-exports everything from the current `sys` for now, I'll move the implementations for the individual features one-by-one after this PR merges.
bors added a commit to rust-lang-ci/rust that referenced this issue Jan 13, 2024
…sDenton

Move platform modules into `sys::pal`

This is the initial step of rust-lang#117276. `sys` just re-exports everything from the current `sys` for now, I'll move the implementations for the individual features one-by-one after this PR merges.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jan 13, 2024
…isDenton

Move personality implementation out of PAL

The module already follows the new convention described in rust-lang#117276. This PR also includes a small fix in the tidy pal check, that was just an oversight in rust-lang#117285.
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Jan 14, 2024
Rollup merge of rust-lang#119935 - joboet:move_pal_personality, r=ChrisDenton

Move personality implementation out of PAL

The module already follows the new convention described in rust-lang#117276. This PR also includes a small fix in the tidy pal check, that was just an oversight in rust-lang#117285.
@rustbot rustbot added the E-help-wanted Call for participation: Help is requested to fix this issue. label Jan 18, 2024
Nadrieril added a commit to Nadrieril/rust that referenced this issue Jan 21, 2024
Move OS String implementation into `sys`

Part of rust-lang#117276. The new structure is really useful here, since we can easily eliminate a number of ugly `#[path]`-based imports.

In the future, it might be good to move the WTF-8 implementation directly to the OS string implementation, I cannot see it being used anywhere else. That is a story for another PR, however.
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Jan 21, 2024
Rollup merge of rust-lang#119996 - joboet:move_pal_os_str, r=ChrisDenton

Move OS String implementation into `sys`

Part of rust-lang#117276. The new structure is really useful here, since we can easily eliminate a number of ugly `#[path]`-based imports.

In the future, it might be good to move the WTF-8 implementation directly to the OS string implementation, I cannot see it being used anywhere else. That is a story for another PR, however.
@ChrisDenton
Copy link
Member

Something that just occurred to me is that we might want to add commits to https://github.com/rust-lang/rust/blob/master/.git-blame-ignore-revs if they're purely moving files. This allows GitHub's blame interface to ignore them.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jan 22, 2024
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jan 22, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Jan 23, 2024
Rollup merge of rust-lang#120109 - joboet:move_pal_cmath, r=ChrisDenton

Move cmath into `sys`

Part of rust-lang#117276.

r? ``@ChrisDenton``
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Feb 9, 2024
Move path implementations into `sys`

Part of rust-lang#117276.

r? `@ChrisDenton`
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Feb 9, 2024
Rollup merge of rust-lang#120776 - joboet:move_pal_path, r=ChrisDenton

Move path implementations into `sys`

Part of rust-lang#117276.

r? `@ChrisDenton`
bors added a commit to rust-lang-ci/rust that referenced this issue Feb 19, 2024
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Mar 2, 2024
…risDenton

Move thread local implementation to `sys`

Part of rust-lang#117276.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Mar 2, 2024
…risDenton

Move thread local implementation to `sys`

Part of rust-lang#117276.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Mar 2, 2024
…risDenton

Move thread local implementation to `sys`

Part of rust-lang#117276.
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Mar 2, 2024
Rollup merge of rust-lang#121758 - joboet:move_pal_thread_local, r=ChrisDenton

Move thread local implementation to `sys`

Part of rust-lang#117276.
bors added a commit to rust-lang-ci/rust that referenced this issue Jun 24, 2024
…=Mark-Simulacrum

std: refactor the TLS implementation

As discovered by Mara in rust-lang#110897, our TLS implementation is a total mess. In the past months, I have simplified the actual macros and their expansions, but the majority of the complexity comes from the platform-specific support code needed to create keys and register destructors. In keeping with rust-lang#117276, I have therefore moved all of the `thread_local_key`/`thread_local_dtor` modules to the `thread_local` module in `sys` and merged them into a new structure, so that future porters of `std` can simply mix-and-match the existing code instead of having to copy the same (bad) implementation everywhere. The new structure should become obvious when looking at `sys/thread_local/mod.rs`.

Unfortunately, the documentation changes associated with the refactoring have made this PR rather large. That said, this contains no functional changes except for two small ones:
* the key-based destructor fallback now, by virtue of sharing the implementation used by macOS and others, stores its list in a `#[thread_local]` static instead of in the key, eliminating one indirection layer and drastically simplifying its code.
* I've switched over ZKVM (tier 3) to use the same implementation as WebAssembly, as the implementation was just a way worse version of that

Please let me know if I can make this easier to review! I know these large PRs aren't optimal, but I couldn't think of any good intermediate steps.

`@rustbot` label +A-thread-locals
bors added a commit to rust-lang-ci/rust that referenced this issue Jun 24, 2024
…=Mark-Simulacrum

std: refactor the TLS implementation

As discovered by Mara in rust-lang#110897, our TLS implementation is a total mess. In the past months, I have simplified the actual macros and their expansions, but the majority of the complexity comes from the platform-specific support code needed to create keys and register destructors. In keeping with rust-lang#117276, I have therefore moved all of the `thread_local_key`/`thread_local_dtor` modules to the `thread_local` module in `sys` and merged them into a new structure, so that future porters of `std` can simply mix-and-match the existing code instead of having to copy the same (bad) implementation everywhere. The new structure should become obvious when looking at `sys/thread_local/mod.rs`.

Unfortunately, the documentation changes associated with the refactoring have made this PR rather large. That said, this contains no functional changes except for two small ones:
* the key-based destructor fallback now, by virtue of sharing the implementation used by macOS and others, stores its list in a `#[thread_local]` static instead of in the key, eliminating one indirection layer and drastically simplifying its code.
* I've switched over ZKVM (tier 3) to use the same implementation as WebAssembly, as the implementation was just a way worse version of that

Please let me know if I can make this easier to review! I know these large PRs aren't optimal, but I couldn't think of any good intermediate steps.

`@rustbot` label +A-thread-locals
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 27, 2024
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 27, 2024
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 27, 2024
joboet added a commit to joboet/rust that referenced this issue Feb 2, 2025
As per rust-lang#117276, this PR moves `sys_common::net` and the `sys::pal::net` into the newly created `sys::net` module. In order to support rust-lang#135141, I've moved all the current network code into a separate `connection` module, future functions like `hostname` can live in separate modules.

I'll probably do a follow-up PR and clean up some of the actual code, this is mostly just a reorganization.
joboet added a commit to joboet/rust that referenced this issue Feb 2, 2025
As per rust-lang#117276, this PR moves `sys_common::net` and the `sys::pal::net` into the newly created `sys::net` module. In order to support rust-lang#135141, I've moved all the current network code into a separate `connection` module, future functions like `hostname` can live in separate modules.

I'll probably do a follow-up PR and clean up some of the actual code, this is mostly just a reorganization.
jieyouxu added a commit to jieyouxu/rust that referenced this issue Feb 5, 2025
std: move network code into `sys`

As per rust-lang#117276, this PR moves `sys_common::net` and the `sys::pal::net` into the newly created `sys::net` module. In order to support rust-lang#135141, I've moved all the current network code into a separate `connection` module, future functions like `hostname` can live in separate modules.

I'll probably do a follow-up PR and clean up some of the actual code, this is mostly just a reorganization.
jieyouxu added a commit to jieyouxu/rust that referenced this issue Feb 5, 2025
std: move network code into `sys`

As per rust-lang#117276, this PR moves `sys_common::net` and the `sys::pal::net` into the newly created `sys::net` module. In order to support rust-lang#135141, I've moved all the current network code into a separate `connection` module, future functions like `hostname` can live in separate modules.

I'll probably do a follow-up PR and clean up some of the actual code, this is mostly just a reorganization.
jieyouxu added a commit to jieyouxu/rust that referenced this issue Feb 5, 2025
std: move network code into `sys`

As per rust-lang#117276, this PR moves `sys_common::net` and the `sys::pal::net` into the newly created `sys::net` module. In order to support rust-lang#135141, I've moved all the current network code into a separate `connection` module, future functions like `hostname` can live in separate modules.

I'll probably do a follow-up PR and clean up some of the actual code, this is mostly just a reorganization.
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Feb 6, 2025
Rollup merge of rust-lang#136449 - joboet:move_pal_net, r=ChrisDenton

std: move network code into `sys`

As per rust-lang#117276, this PR moves `sys_common::net` and the `sys::pal::net` into the newly created `sys::net` module. In order to support rust-lang#135141, I've moved all the current network code into a separate `connection` module, future functions like `hostname` can live in separate modules.

I'll probably do a follow-up PR and clean up some of the actual code, this is mostly just a reorganization.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Feb 8, 2025
std: move `io` module out of `pal`, get rid of `sys_common::io`

Part of rust-lang#117276.

This does two related things:
1. It moves the platform-specific definitions for `IoSlice`, `IoSliceMut` and `is_terminal` out of `pal` and into `sys` and unifies some of them.
2. It gets rid of `sys_common::io`, moving the non-platform-specific test helpers into `std::test_helpers` and the buffer size definition to the new `sys::io` module.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Feb 8, 2025
std: move `io` module out of `pal`, get rid of `sys_common::io`

Part of rust-lang#117276.

This does two related things:
1. It moves the platform-specific definitions for `IoSlice`, `IoSliceMut` and `is_terminal` out of `pal` and into `sys` and unifies some of them.
2. It gets rid of `sys_common::io`, moving the non-platform-specific test helpers into `std::test_helpers` and the buffer size definition to the new `sys::io` module.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Feb 8, 2025
std: move `io` module out of `pal`, get rid of `sys_common::io`

Part of rust-lang#117276.

This does two related things:
1. It moves the platform-specific definitions for `IoSlice`, `IoSliceMut` and `is_terminal` out of `pal` and into `sys` and unifies some of them.
2. It gets rid of `sys_common::io`, moving the non-platform-specific test helpers into `std::test_helpers` and the buffer size definition to the new `sys::io` module.
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Feb 8, 2025
Rollup merge of rust-lang#135696 - joboet:move_pal_io, r=Noratrieb

std: move `io` module out of `pal`, get rid of `sys_common::io`

Part of rust-lang#117276.

This does two related things:
1. It moves the platform-specific definitions for `IoSlice`, `IoSliceMut` and `is_terminal` out of `pal` and into `sys` and unifies some of them.
2. It gets rid of `sys_common::io`, moving the non-platform-specific test helpers into `std::test_helpers` and the buffer size definition to the new `sys::io` module.
joboet added a commit to joboet/rust that referenced this issue Feb 9, 2025
As per rust-lang#117276, this moves the platform definitions of `Stdout` and friends into `sys`. This PR also unifies the UNIX and Hermit implementations and moves the `__rust_print_err` function needed by libunwind on SGX into the dedicated module for such helper functions.
joboet added a commit to joboet/rust that referenced this issue Feb 9, 2025
As per rust-lang#117276, this moves the platform definitions of `Stdout` and friends into `sys`. This PR also unifies the UNIX and Hermit implementations and moves the `__rust_print_err` function needed by libunwind on SGX into the dedicated module for such helper functions.
joboet added a commit to joboet/rust that referenced this issue Feb 12, 2025
As per rust-lang#117276, this moves the implementations of `Process` and friends out of the `pal` module and into the `sys` module, removing quite a lot of error-prone `#[path]` imports in the process (hah, get it ;-)). I've also made the `zircon` module a dedicated submodule of `pal::unix`, hopefully we can move some other definitions there as well (they are currently quite a lot of duplications in `sys`). Also, the `ensure_no_nuls` function on Windows now lives in `sys::pal::windows` – it's not specific to processes and shared by the argument implementation.
joboet added a commit to joboet/rust that referenced this issue Feb 12, 2025
As per rust-lang#117276, this moves the implementations of `Process` and friends out of the `pal` module and into the `sys` module, removing quite a lot of error-prone `#[path]` imports in the process (hah, get it ;-)). I've also made the `zircon` module a dedicated submodule of `pal::unix`, hopefully we can move some other definitions there as well (they are currently quite a lot of duplications in `sys`). Also, the `ensure_no_nuls` function on Windows now lives in `sys::pal::windows` – it's not specific to processes and shared by the argument implementation.
joboet added a commit to joboet/rust that referenced this issue Feb 13, 2025
As per rust-lang#117276, this moves the implementations of `Process` and friends out of the `pal` module and into the `sys` module, removing quite a lot of error-prone `#[path]` imports in the process (hah, get it ;-)). I've also made the `zircon` module a dedicated submodule of `pal::unix`, hopefully we can move some other definitions there as well (they are currently quite a lot of duplications in `sys`). Also, the `ensure_no_nuls` function on Windows now lives in `sys::pal::windows` – it's not specific to processes and shared by the argument implementation.
joboet added a commit to joboet/rust that referenced this issue Feb 15, 2025
As per rust-lang#117276, this moves the platform definitions of `Stdout` and friends into `sys`. This PR also unifies the UNIX and Hermit implementations and moves the `__rust_print_err` function needed by libunwind on SGX into the dedicated module for such helper functions.
joboet added a commit to joboet/rust that referenced this issue Feb 15, 2025
As per rust-lang#117276, this moves the implementations of `Process` and friends out of the `pal` module and into the `sys` module, removing quite a lot of error-prone `#[path]` imports in the process (hah, get it ;-)). I've also made the `zircon` module a dedicated submodule of `pal::unix`, hopefully we can move some other definitions there as well (they are currently quite a lot of duplications in `sys`). Also, the `ensure_no_nuls` function on Windows now lives in `sys::pal::windows` – it's not specific to processes and shared by the argument implementation.
joboet added a commit to joboet/rust that referenced this issue Feb 17, 2025
As per rust-lang#117276, this moves the implementations of `Process` and friends out of the `pal` module and into the `sys` module, removing quite a lot of error-prone `#[path]` imports in the process (hah, get it ;-)). I've also made the `zircon` module a dedicated submodule of `pal::unix`, hopefully we can move some other definitions there as well (they are currently quite a lot of duplications in `sys`). Also, the `ensure_no_nuls` function on Windows now lives in `sys::pal::windows` – it's not specific to processes and shared by the argument implementation.
joboet added a commit to joboet/rust that referenced this issue Feb 17, 2025
As per rust-lang#117276, this moves the platform definitions of `Stdout` and friends into `sys`. This PR also unifies the UNIX and Hermit implementations and moves the `__rust_print_err` function needed by libunwind on SGX into the dedicated module for such helper functions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC E-help-wanted Call for participation: Help is requested to fix this issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants