Fix duration_since panic on unix when std is built with integer overflow checks

[stepancheg]

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

[stepancheg]

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

[stepancheg]

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]

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]

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

[stepancheg]

Found it.

rust.overflow-checks = true

[workingjubilee]

Ah, yes, down a few lines then.

[RalfJung]

r? libs
since this actually changes the implementation

[stepancheg]

Ping @tgross35.

[joboet]

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?

[stepancheg]

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.

[tgross35]

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

[stepancheg]

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]

Ping @tgross35.

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

[rustbot]

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]

@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]

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.