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
13 of 14 tasks
joboet opened this issue Oct 27, 2023 · 1 comment
Open
13 of 14 tasks

Tracking Issue for restructuring std::sys #117276

joboet opened this issue Oct 27, 2023 · 1 comment
Assignees
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. 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

  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

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

@joboet joboet added the C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. 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.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Mar 13, 2024
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Mar 13, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Mar 13, 2024
Rollup merge of rust-lang#122386 - joboet:move_pal_once, r=jhpratt

Move `Once` implementations to `sys`

Part of rust-lang#117276.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Apr 12, 2024
Remove `sys_common::thread`

Part of rust-lang#117276.

The stack size calculation isn't system-specific at all and can just live together with the rest of the spawn logic.
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Apr 12, 2024
Rollup merge of rust-lang#123807 - joboet:sys_common_thread, r=jhpratt

Remove `sys_common::thread`

Part of rust-lang#117276.

The stack size calculation isn't system-specific at all and can just live together with the rest of the spawn logic.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue May 4, 2024
…ChrisDenton

Move thread parking to `sys::sync`

Part of rust-lang#117276.

I'll leave the platform-specific API abstractions in `sys::pal`, as per the initial proposal. I'm not entirely sure whether we'll want to keep it that way, but that remains to be seen.

r? `@ChrisDenton` (if you have time)
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue May 4, 2024
…ChrisDenton

Move thread parking to `sys::sync`

Part of rust-lang#117276.

I'll leave the platform-specific API abstractions in `sys::pal`, as per the initial proposal. I'm not entirely sure whether we'll want to keep it that way, but that remains to be seen.

r? ``@ChrisDenton`` (if you have time)
rust-timer added a commit to rust-lang-ci/rust that referenced this issue May 4, 2024
Rollup merge of rust-lang#124159 - joboet:move_pal_thread_parking, r=ChrisDenton

Move thread parking to `sys::sync`

Part of rust-lang#117276.

I'll leave the platform-specific API abstractions in `sys::pal`, as per the initial proposal. I'm not entirely sure whether we'll want to keep it that way, but that remains to be seen.

r? ``@ChrisDenton`` (if you have time)
joboet added a commit to joboet/rust that referenced this issue Jun 15, 2024
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` functions to the `thread_local` module in `sys` and given them 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
joboet added a commit to joboet/rust that referenced this issue Jun 15, 2024
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
jieyouxu added a commit to jieyouxu/rust that referenced this issue Jun 16, 2024
…ngjubilee

std: move `sys_common::backtrace` to `sys`

Part of rust-lang#117276.
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Jun 16, 2024
Rollup merge of rust-lang#126546 - joboet:move_pal_backtrace, r=workingjubilee

std: move `sys_common::backtrace` to `sys`

Part of rust-lang#117276.
compiler-errors added a commit to compiler-errors/rust that referenced this issue Jun 23, 2024
… r=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 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. 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