-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
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
added
the
C-tracking-issue
Category: A tracking issue for an RFC or an unstable feature.
label
Oct 27, 2023
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.
This was referenced Jan 15, 2024
Merged
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.
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
Move cmath into `sys` Part of rust-lang#117276. r? `@ChrisDenton`
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Jan 22, 2024
Move cmath into `sys` Part of rust-lang#117276. r? ``@ChrisDenton``
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`
Merged
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Feb 19, 2024
Move locks to `sys` Part of rust-lang#117276. r? `@ChrisDenton`
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
Move `Once` implementations to `sys` Part of rust-lang#117276.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Mar 13, 2024
Move `Once` implementations to `sys` Part of rust-lang#117276.
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
std: move allocators to `sys` Part of rust-lang#117276.
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Aug 27, 2024
std: move allocators to `sys` Part of rust-lang#117276.
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Aug 27, 2024
std: move allocators to `sys` Part of rust-lang#117276.
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.
On Wednesday, the libs-team discussed reorganizing the platform-specific modules inside
std
, namelysys
andsys_common
into a new structure. These modules will be merged into onesys
module with a feature-first organization:sys
, named after the feature they implement, contain all the implementations of the different platforms and provide a uniform interface that the rest ofstd
may depend on. E.g.sys::thread_local
,sys::fs
orsys::thread_parking
.sys::pal
contains platform-specific generic API wrappers likeFileDesc
cvt
(UNIX) used to implement these features. E.g.sys::pal::unix
,sys::pal::windows
or (perhaps)sys::pal::apple
.The rest of
std
, modulostd::os
, should now only depend onsys::feature_name
and notsys::pal
. The implementations themselves may however depend on other parts ofstd
as necessary.Tasks
sys::pal
#117285sys
#119996sys
#120109sys
#120776sys
#121177sys
#121758Once
implementations tosys
#122386sys_common::thread
#123807sys::sync
#124159sys_common::backtrace
tosys
#126546sys
#128134@rustbot label +T-libs +E-help-wanted
@rustbot claim
The text was updated successfully, but these errors were encountered: