std: move time implementations to sys
#151161
Open
+638
−689
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Let's start with the easy ones: * Motor just reexports its platform library * The SGX code is just a trivial move * Trusty, WASM and ZKVM are unsupported, this is very trivial. And we can get rid of some `#[path = ...]`s, yay!
Now that the `unsupported` module exists, we can use it for VEX. VEX actually supports `Instant` though, so the implementation-select needs to combine that with the `unsupported` module.
On SOLID, the conversion functions are also used to implement helpers for timeout conversion, so these stay in the PAL. The `Instant` (µITRON) and `SystemTime` (SOLID-specific) implementations are merged into one. While it was nice to have the µITRON parts in a separate module, there really isn't a need for this currently, as there is no other µITRON target. Let's not worry about this until such a target gets added... Note that I've extracted the `get_tim` call from `Instant` into a wrapper function in the PAL to avoid the need to make the inner `Instant` field public for use in the PAL.
Next up: UEFI. Unfortunately the time conversion internals are also required by the filesystem code, so I've left them in the PAL. The `Instant` internals however are only used for the `Instant` implementation, so I've moved them to `sys` (for now).
Collaborator
rustbot
added
O-itron
30 tasks
This comment has been minimized.
This comment has been minimized.
Member
Author
|
I've changed my mind, I'll just move these in their entirety. |
rustbot
removed
the
S-waiting-on-review
Member
Author
|
Ok, no, let's actually do it this way first... |
rustbot
added
the
S-waiting-on-review
Windows has a similar problem as UEFI: some internals are also used for implementing other things. Thus I've left everything except for the actual `Instant` and `SystemTime` implementations inside the PAL. I've also taken the liberty of improving the code clarity a bit: there were a number of manual `SystemTime` conversions (including one that masked an `i64` to 32-bits before casting to `u32`, yikes) that now just call `from_intervals`. Also, defining a `PerformanceCounterInstant` just to convert it to a regular `Instant` immediately doesn't really make sense to me. I've thus changed the `perf_counter` module to contain only free functions that wrap system functionality. The actual conversion now happens in `Instant::now`.
Now for UNIX: `Timespec` is also used for things like futex or `Condvar` timeouts, so it stays in the PAL along with some related definitions. Everything else is `SystemTime`- and `Instant`-specific, and is thus moved to `sys::time`.
WASI and TEEOS share the UNIX implementation. Since `Timespec` lives in the PAL, this means that the `#[path]` imports of `unix/time.rs` still remain for these two, unfortunately. Maybe we'll solve that in the future by always including the UNIX PAL for these remotely UNIXy platforms. But that's a story for another time...
Last on the list: Hermit. Since I anticipate that Hermit will share the UNIX implementation in the future, I've left `Timespec` in the PAL to maintain a similar structure. Also, I noticed that some public `Instant` methods were redefined on the internal `Instant`. But the networking code can just use the public `Instant`, so I've removed them.
This comment has been minimized.
This comment has been minimized.
The `std` paths are subject to change, but the values themselves will never change.
Collaborator
|
The Miri subtree was changed cc @rust-lang/miri |
RalfJung
reviewed
Jan 17, 2026
| let INTERVALS_TO_UNIX_EPOCH = this.eval_windows_u64("time", "INTERVALS_TO_UNIX_EPOCH"); | ||
| let SECONDS_TO_UNIX_EPOCH = INTERVALS_TO_UNIX_EPOCH / INTERVALS_PER_SEC; | ||
| // The amount of seconds between 1601/1/1 and 1970/1/1. | ||
| const SECONDS_TO_UNIX_EPOCH: u64 = 11_644_473_600; |
Member
There was a problem hiding this comment.
If we can't use values from std here any more, the comment should have links that show why this is the right value.
(Same for the other case further down the file.)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is probably the most complex step of #117276 so far. Unfortunately, quite some of the internal time logic defined in the PAL is also used in other places like the filesystem code, so this isn't just a series of simple moves. I've left all that logic inside the PAL and only moved the actual
SystemTime/Instantimplementations.While there are no functional changes, this PR also contains some slight code cleanups on Windows and Hermit, these are explained in the relevant commits.
For additional details see the individual commits, I've tried to make the messages as helpful as possible about what's going on.