Rollup of 7 pull requests #149974
Closed
Rollup of 7 pull requests #149974
+1,790
−1,523
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
This commit introduces two new constants to SystemTime: `MIN` and `MAX`, whose value represent the maximum values for the respective data type, depending upon the platform. Technically, this value is already obtainable during runtime with the following algorithm: Use `SystemTime::UNIX_EPOCH` and call `checked_add` (or `checked_sub`) repeatedly with `Duration::new(0, 1)` on it, until it returns None. Mathematically speaking, this algorithm will terminate after a finite amount of steps, yet it is impractical to run it, as it takes practically forever. Besides, this commit also adds a unit test. Concrete implementation depending upon the platform is done in later commits. In the future, the hope of the authors lies within the creation of a `SystemTime::saturating_add` and `SystemTime::saturating_sub`, similar to the functions already present in `std::time::Duration`. However, for those, these constants are crucially required, thereby this should be seen as the initial step towards this direction. Below are platform specifc notes: # Hermit The HermitOS implementation is more or less identitcal to the Unix one. # sgx The implementation uses a `Duration` to store the Unix time, thereby implying `Duration::ZERO` and `Duration::MAX` as the limits. # solid The implementation uses a `time_t` to store the system time within a single value (i.e. no dual secs/nanosecs handling), thereby implying its `::MIN` and `::MAX` values as the respective boundaries. # UEFI UEFI has a weird way to store times, i.e. a very complicated struct. The standard proclaims "1900-01-01T00:00:00+0000" to be the lowest possible value and `MAX_UEFI_TIME` is already present for the upper limit. # Windows Windows is weird. The Win32 documentation makes no statement on a maximum value here. Next to this, there are two conflicting types: `SYSTEMTIME` and `FILETIME`. Rust's Standard Library uses `FILETIME`, whose limit will (probably) be `i64::MAX` packed into two integers. However, `SYSTEMTIME` has a lower-limit. # xous It is similar to sgx in the sense of using a `Duration`. # unsupported Unsupported platforms store a `SystemTime` in a `Duration`, just like sgx, thereby implying `Duration::ZERO` and `Duration::MAX` as the respective limits.
This updates to mdbook 0.5.2 from mdbook 0.4.52. A primary aspect of this change is that it splits the `mdbook` crate into multiple crates, and various API changes and cleanup. There's full release notes and a migration guide at https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-050. This also includes submodule updates: ## book 2 commits in 8c0eacd5c4acbb650497454f3a58c9e8083202a4..39aeceaa3aeab845bc4517e7a44e48727d3b9dbe 2025-11-18 10:36:41 -0500 to 2025-12-12 11:02:27 -0500 - Synchronize TrplNote name - Update to mdbook 0.5 ## edition-guide 1 commits in 9cf5443d632673c4d41edad5e8ed8be86eeb3b8f..c3c0f0b3da26610138b7ba7663f60cd2c68cf184 2025-11-15 21:51:11 +0000 to 2025-11-28 18:54:18 +0000 - Update to mdbook 0.5 (rust-lang/edition-guide#381) ## nomicon 2 commits in 0fe83ab28985b99aba36a1f0dbde3e08286fefda..9fe8fa599ad228dda74f240cc32b54bc5c1aa3e6 2025-11-15 00:03:14 +0000 to 2025-12-03 11:54:04 +0000 - Remove references to outdated unsafe code guidelines (rust-lang/nomicon#512) - Update to mdbook 0.5 (rust-lang/nomicon#511) ## reference 5 commits in b14b4e40f53ca468beaf2f5d0dfb4f4c4ba6bc7b..50c5de90487b68d429a30cc9466dc8f5b410128f 2025-12-02 21:17:44 +0000 to 2025-12-09 22:19:05 +0000 - UB: update the extra clause for provenance UB during const evaluation (rust-lang/reference#2091) - Remove `[no-mentions]` handler in our triagebot config (rust-lang/reference#2102) - Clarify that omitting `nostack` is a promise from the compiler to the programmer (rust-lang/reference#1999) - Specify that range patterns must be nonempty. (rust-lang/reference#2093) - Update to mdbook 0.5 (rust-lang/reference#2096) ## rust-by-example 1 commits in 111cfae2f9c3a43f7b0ff8fa68c51cc8f930637c..7d21279e40e8f0e91c2a22c5148dd2d745aef8b6 2025-11-27 17:16:42 -0300 to 2025-12-01 15:02:09 -0300 - Update to mdbook 0.5 (rust-lang/rust-by-example#1977)
This solves the "can't find the upvar" ICEs that resulted from `maybe_read_scrutinee` being unfit for purpose.
The split between walk_pat and maybe_read_scrutinee has now become redundant. Due to this change, one testcase within the testsuite has become similar enough to a known ICE to also break. I am leaving this as future work, as it requires feature(type_alias_impl_trait)
As per code review, it is preferred to not use derives in tests that aren't about them.
This aims to make each major part responsible for modifying the precision be visible in the logs.
As Nadrieril remarked, the previous comment was misleadingly framed.
See clippy issue 16086 for context
Expect the entire input to be a single XML document, instead of reading it line by line. This detects trailing junk better.
Copied validate_junit.py from libtest-junit. JUnit format works well in edition 2021, but is currently broken in edition 2024 by the mergeable doctest report.
Fix the panic in write_message() which expects messages to contain no embedded newlines. We still want a trailing newline at the end of the file though, so write it in different manner. Doctest runner no longer panics, but the output is kinda broken when `compile_fail` doctests are present. This is because they are not mergeable.
There is a slight edge case when adding and subtracting a `Duration` from a `SystemTime`, namely when the duration itself is finer/smaller than the time precision on the operating systems. On most (if not all non-Windows) operating systems, the precision of `Duration` aligns with the `SystemTime`, both being one nanosecond. However, on Windows, this time precision is 100ns, meaning that adding or subtracting a `Duration` whose value is `< Duration::new(0, 100)` will result in that method behaving like an addition/subtracting of `Duration::ZERO`, due to the `Duration` getting rounded-down to the zero value.
The Windows implementation of `SystemTime::checked_sub` contains a bug, namely that it does not return `None` on values below 1601. This bug stems from the fact that internally, the time gets converted to an i64, with zero representing the anchor in 1601. Of course, performing checked subtraction on a signed integer generally works fine. However, the resulting value delivers undefined behavior on Windows systems. To mitigate this issue, we try to convert the resulting i64 to an u64 because a negative value should obviously fail there.
…=ChrisDenton
Add SystemTime::{MIN, MAX}
Accepted ACP: <rust-lang/libs-team#692>
Tracking Issue: <rust-lang#149067>
---
This merge request introduces two new constants to `SystemTime`: `MIN` and `MAX`, whose values represent the maximum values for the respective data type, depending upon the platform.
Technically, this value is already obtainable during runtime with the following algorithm:
Use `SystemTime::UNIX_EPOCH` and call `checked_add` (or `checked_sub`) repeatedly with `Duration::new(0, 1)` on it, until it returns None.
Mathematically speaking, this algorithm will terminate after a finite amount of steps, yet it is impractical to run it, as it takes practically forever.
Besides, this commit also adds a unit test to verify those values represent the respective minimum and maximum, by letting a `checked_add` and `checked_sub` on it fail.
In the future, the hope of the authors lies within the creation of a `SystemTime::saturating_add` and `SystemTime::saturating_sub`, similar to the functions already present in `std::time::Duration`.
However, for those, these constants are crucially required, thereby this should be seen as the initial step towards this direction.
With this change, implementing these functions oneself outside the standard library becomes feasible in a portable manner for the first time.
This feature (and a related saturating version of `checked_{add, sub}` has been requested multiple times over the course of the past few years, most notably:
* rust-lang#100141
* rust-lang#133525
* rust-lang#105762
* rust-lang#71224
* rust-lang#45448
* rust-lang#52555
…Mark-Simulacrum tidy: Detect outdated workspaces in workspace list Detects the case in rust-lang#149415 (will pass CI once that lands).
Fix trailing newline in JUnit formatter `write_message()` expects messages to contain no newlines. Fixes rust-lang#149436
Update to mdbook 0.5 This updates to mdbook 0.5.2 from mdbook 0.4.52. A primary aspect of this change is that it splits the `mdbook` crate into multiple crates, and various API changes and cleanup. There's full release notes and a migration guide at https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-050. This also includes submodule updates: ## book 1 commits in 8c0eacd5c4acbb650497454f3a58c9e8083202a4..9c9104e8a82430f97f42e738051bda718919211c 2025-11-18 10:36:41 -0500 to 2025-12-10 11:33:49 -0500 - Update to mdbook 0.5 ## edition-guide 1 commits in 9cf5443d632673c4d41edad5e8ed8be86eeb3b8f..c3c0f0b3da26610138b7ba7663f60cd2c68cf184 2025-11-15 21:51:11 +0000 to 2025-11-28 18:54:18 +0000 - Update to mdbook 0.5 (rust-lang/edition-guide#381) ## nomicon 2 commits in 0fe83ab28985b99aba36a1f0dbde3e08286fefda..9fe8fa599ad228dda74f240cc32b54bc5c1aa3e6 2025-11-15 00:03:14 +0000 to 2025-12-03 11:54:04 +0000 - Remove references to outdated unsafe code guidelines (rust-lang/nomicon#512) - Update to mdbook 0.5 (rust-lang/nomicon#511) ## reference 5 commits in b14b4e40f53ca468beaf2f5d0dfb4f4c4ba6bc7b..50c5de90487b68d429a30cc9466dc8f5b410128f 2025-12-02 21:17:44 +0000 to 2025-12-09 22:19:05 +0000 - UB: update the extra clause for provenance UB during const evaluation (rust-lang/reference#2091) - Remove `[no-mentions]` handler in our triagebot config (rust-lang/reference#2102) - Clarify that omitting `nostack` is a promise from the compiler to the programmer (rust-lang/reference#1999) - Specify that range patterns must be nonempty. (rust-lang/reference#2093) - Update to mdbook 0.5 (rust-lang/reference#2096) ## rust-by-example 1 commits in 111cfae2f9c3a43f7b0ff8fa68c51cc8f930637c..7d21279e40e8f0e91c2a22c5148dd2d745aef8b6 2025-11-27 17:16:42 -0300 to 2025-12-01 15:02:09 -0300 - Update to mdbook 0.5 (rust-lang/rust-by-example#1977)
…donszelmann Cleanup of attribute parsing errors Removes the specific `UnknownMetaItem` and `IllFormedAttributeInputLint` errors. Note that `IllFormedAttributeInputLint` is not a lint, contrary to its name r? ```@jdonszelmann```
Fix typo in armv7a-vex-v5 documentation Fixed a typo in the platform support documentation for the `armv7a-vex-v5` target.
rustbot
added
A-attributes
Member
Author
|
@bors r+ rollup=never p=5 |
Collaborator
bors
added
S-waiting-on-bors
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Member
Author
|
@bors r- |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
12 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.
Successful merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup