Skip to content

Conversation

stepancheg
Copy link
Contributor

@stepancheg stepancheg commented Sep 14, 2025

Add a test for regression #146228, and turns out this test fails detects error when std is compiled with integer overflow checks.

Original regression was reverted in #146473.

First attempt to fix was in #146247; test and some code is copied from there, thanks @eval-exec

r? @RalfJung

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Sep 14, 2025
@stepancheg stepancheg changed the title Repro duration_since regression from issue 146228 Test for (reverted now) duration_since regression Sep 14, 2025
@rust-log-analyzer

This comment has been minimized.

@stepancheg
Copy link
Contributor Author

Seems like the bug was there before constify of SystemTime, but did not manifest in debug builds. I'll try to fix.

@stepancheg
Copy link
Contributor Author

If anyone is around, not do I compile std with debug assertions including integer overflow? I'm running

./x test library/std --no-doc

and such assertions are not triggered.

@workingjubilee
Copy link
Member

put this in your bootstrap.toml

rust.debug-assertions-std = true

from

rust/bootstrap.example.toml

Lines 603 to 604 in 52618eb

# Defaults to rust.debug-assertions value
#rust.debug-assertions-std = rust.debug-assertions (boolean)

@stepancheg
Copy link
Contributor Author

stepancheg commented Sep 14, 2025

@workingjubilee this seems to enable debug_assert!, but does not trigger integer overflow checks.

@stepancheg
Copy link
Contributor Author

Found it.

rust.overflow-checks = true

@rustbot rustbot added O-hermit Operating System: Hermit O-unix Operating system: Unix-like labels Sep 14, 2025
@stepancheg stepancheg changed the title Test for (reverted now) duration_since regression Fix duration_since panic on unix when std is built with integer overflow checks Sep 14, 2025
@workingjubilee
Copy link
Member

Ah, yes, down a few lines then.

@RalfJung
Copy link
Member

r? libs
since this actually changes the implementation

@rustbot rustbot assigned tgross35 and unassigned RalfJung Sep 15, 2025
@rustbot

This comment has been minimized.

@stepancheg
Copy link
Contributor Author

Ping @tgross35.

} else {
(
(self.tv_sec - other.tv_sec - 1) as u64,
(self.tv_sec - 1).wrapping_sub(other.tv_sec) as u64,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had to think for a few seconds before I realised why the - 1 couldn't panic (since other.tv_nsec is larger than self.tv_nsec, but other smaller than self, other.tv_sec must be smaller than self.tv_sec, meaning that there is a value smaller than self.tv_sec, making the subtraction work). Could you perhaps add a comment to explain it? Or use wrapping_sub for the decrement as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a few assertions, so that sequence of assertion will explain why it does not underflow.

Or use wrapping_sub for the decrement as well?

That would not be right, because if there is a bug here, instead of debug assertion, we may quietly get wrong result.

// is outside of the `if`-`else`, not duplicated in both branches
//
// Ideally this code could be rearranged such that it more
// directly expresses the lower-cost behavior we want from it.
Copy link
Contributor

@tgross35 tgross35 Sep 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment above here needs to be updated, considering it specifically calls out self.tv_sec - 1 - other.tv_sec vs. self.tv_sec - other.tv_sec - 1. I don't think it's all relevant anymore, given https://rust.godbolt.org/z/1Ex913qr5

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed the comment because:

  • you asked to update it
  • I don't understand it
  • this does not seem like performance critical code to do

@tgross35
Copy link
Contributor

Ping @tgross35.

Hey, this was open for only three days :) I don't think this is high priority?

@rustbot
Copy link
Collaborator

rustbot commented Sep 19, 2025

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

@stepancheg
Copy link
Contributor Author

stepancheg commented Sep 19, 2025

@tgross35

I don't think this is high priority?

The bugfix is not high priority, but I wanted to add a couple PRs on top, and if each one takes weeks to review, I will lose context and/or switch to some other work (my primary work is far from opensource).

Sorry for the ping. Is there expected time to a comment from the reviewer for a PR in rust repo so next time I'll avoid pinging the maintainers too early?

@RalfJung
Copy link
Member

The comment that the bot posts for new contributors says

They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
O-hermit Operating System: Hermit O-unix Operating system: Unix-like S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants