A `Duration` is created from a second and nanoseconds variable. The
documentation says: "This constructor will panic if the carry from the
nanoseconds overflows the seconds counter". This was, however, not tested
in the tests. I doubt the behavior will ever regress, but it is usually a
good idea to test all documented behavior.
Update Clippy from 2855b21 to 8fbb23f
```
Fix ICE in `missing_errors_doc`
Update License
Migrate Clippy to GitHub Actions
redundant_clone: Migrate to new dataflow framework
Move unneeded_field_pattern to pedantic group
Rustup to rust-lang/rust#69325
Rustup to rust-lang/rust#69072
```
Fixes#69338
r? @Manishearth
Check `RUSTC_CTFE_BACKTRACE` much less by generating fewer errors
Before this change, `get_size_and_align()` calls `get_fn_alloc()` *a
lot* in CTFE heavy code. This previously returned an `Error` which would
check if `RUSTC_CTFE_BACKTRACE` was set on construction. Doing this
turned out to be a performance hotspot as @nnethercote discovered in
#68792.
This is an alternate take on that PR which resolves the performance
issue by generating *many* fewer errors. Previously, `ctfe-stress-4`
would generate over 5,000,000 errors each of which would check for the
presence of the environment variable. With these changes, that number is
reduced to 30.
r? @RalfJung
To my knowledge, there is essentially never any particular action that the
infra team needs to take on these pings, and they are currently relatively
annoying.
`SipHasher128`'s `u8to64_le` function was simplified in #68914.
Unfortunately, the new version is slower, because it introduces `memcpy`
calls with non-statically-known lengths.
This commit reverts the change, and adds an explanatory comment (which
is also added to `libcore/hash/sip.rs`). This barely affects
`SipHasher128`'s speed because it doesn't use `u8to64_le` much, but it
does result in `SipHasher128` once again being consistent with
`libcore/hash/sip.rs`.
