Rollup of 9 pull requests #57879
Merged
Rollup of 9 pull requests #57879
Conversation
This file contains 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
Right now we do unit conversions between PerfCounter measurements and nanoseconds for every add/sub we do between Durations and Instants on Windows machines. This leads to goofy behavior, like this snippet failing: ``` let now = Instant::now(); let offset = Duration::from_millis(5); assert_eq!((now + offset) - now, (now - now) + offset); ``` with precision problems like this: ``` thread 'main' panicked at 'assertion failed: `(left == right)` left: `4.999914ms`, right: `5ms`', src\main.rs:6:5 ``` To fix it, this changeset does the unit conversion once, when we measure the clock, and all the subsequent math in u64 nanoseconds. It also adds an exact associativity test to the `sys/time.rs` test suite to make sure we don't regress on this in the future.
Per review comments, this commit switches out the backing type for Instant on windows to a Duration. Tests all pass, and the code's a lot simpler (plus it should be portable now, with the exception of the QueryPerformanceWhatever functions).
This function takes a generator and wraps it in a future, not vice-versa.
This commit adds a suggestion when a `=` character is used when specifying the value of a field in a struct constructor incorrectly instead of a `:` character.
Fix Instant/Duration math precision & associativity on Windows
**tl;dr** Addition and subtraction on Duration/Instant are not associative on windows because we use the perfcounter frequency in every calculation instead of just when we measure time.
This is my first contrib (PR or Issue) to Rust, so please lmk if I've done this wrong. I followed CONTRIBUTING to the extent I could given my system doesn't seem to be able to build the compiler with changes in the source tree. I also asked about this issue in #rust-beginners a week or so ago, before digging through libstd -- I'm unsure if there's a good way to follow up on that, but I'd be happy to update the docs on the timing structs if this fixes the problem.
## Issue
The `Duration` type keeps seconds in the upper-64 and nanoseconds in the lower-32 bits. In theory doing math on these ought to be basically the same as doing math on any other 64 or 32 bit integral number.
On windows (and I think macos too), however, our math gets messy because the Instant type stores the current point in time in units of HPET Performance Counter counts, not nanoseconds, and does unit conversions on every math operation, rather than just when we measure the time from the system clock.
I tried this code:
```
use std::time::{Duration, Instant};
fn main() {
let now = Instant::now();
let offset = Duration::from_millis(5);
assert_eq!((now + offset) - now, (now - now) + offset);
}
```
On UNIX machines (linux and macos) it behaves as you'd expect -- [no crash](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=cf2206c0b7e07d8ecc7767a512364094).
On Windows hosts, however, it blows up because of a precision problem in the Instant +/- Duration math:
```
C:\Users\aberg\work\timetest (master -> origin)
λ cargo run
Finished dev [unoptimized + debuginfo] target(s) in 0.02s
Running `target\debug\timetest.exe`
thread 'main' panicked at 'assertion failed: `(left == right)`
left: `4.999914ms`,
right: `5ms`', src\main.rs:6:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: process didn't exit successfully: `target\debug\timetest.exe` (exit code: 101)
C:\Users\aberg\work\timetest (master -> origin)
λ cat src\main.rs
use std::time::{Duration, Instant};
fn main() {
let now = Instant::now();
let offset = Duration::from_millis(5);
assert_eq!((now + offset) - now, (now - now) + offset);
}
```
On windows I think this is a consequence of doing the HPET-PerfCounter-Unit conversion on each math operation. I suspect the reason it works on macs is that (from what I could find online) most apple machines report timing in nanoseconds anyway. For anyone interested, the equivalent functions on macos, with a little work to fish out the numerator/denominator from a timebase struct:
* `QueryPerformanceCounter()` -> `mach_absolute_time()`
* `QueryPerformanceFrequency()` -> `mach_timebase_info()`
If this PR ends up working as I expect it to when CI runs the tests, I can make the same changes to the macos implementation.
## Potential Fix
We ought to be able to sort this out by storing nanoseconds, rather than PerfCounter units, that way intermediate math is done in the most precise units we support and we're only doing unit conversions when we actually measure the system clock (and it might even translate to a small perf gain for people doing tons of Instant/Duration math).
I believe this will address the underlying cause of rust-lang#56034, and make the guessed epsilon constant from rust-lang#56059 unnecessary. If it's of interest, I can write up how these timing types work on the tier 1 platforms to address rust-lang#32626 as well, since I'm already in here figuring it out.
## This Patch
To that end, I've got this patch, which I think should fix it on windows, but I'm having trouble testing it -- any time I change anything in libstd I start getting this error, which no amount of clean building seems to resolve:
```
C:\Users\aberg\work\rust (master -> origin)
λ python x.py test --stage 0 --no-doc src/libstd
Updating only changed submodules
Submodules updated in 0.27 seconds
Finished dev [unoptimized] target(s) in 2.41s
Building stage0 std artifacts (x86_64-pc-windows-msvc -> x86_64-pc-windows-msvc)
Finished release [optimized] target(s) in 6.78s
Copying stage0 std from stage0 (x86_64-pc-windows-msvc -> x86_64-pc-windows-msvc / x86_64-pc-windows-msvc)
Building stage0 test artifacts (x86_64-pc-windows-msvc -> x86_64-pc-windows-msvc)
Compiling test v0.0.0 (C:\Users\aberg\work\rust\src\libtest)
error[E0460]: found possibly newer version of crate `std` which `getopts` depends on
--> src\libtest\lib.rs:36:1
|
36 | extern crate getopts;
| ^^^^^^^^^^^^^^^^^^^^^
|
= note: perhaps that crate needs to be recompiled?
= note: the following crate versions were found:
crate `std`: \\?\C:\Users\aberg\work\rust\build\x86_64-pc-windows-msvc\stage0-sysroot\lib\rustlib\x86_64-pc-windows-msvc\lib\libstd-d7a80ca2ae113c97.rlib
crate `std`: \\?\C:\Users\aberg\work\rust\build\x86_64-pc-windows-msvc\stage0-sysroot\lib\rustlib\x86_64-pc-windows-msvc\lib\std-d7a80ca2ae113c97.dll
crate `getopts`: \\?\C:\Users\aberg\work\rust\build\x86_64-pc-windows-msvc\stage0-test\x86_64-pc-windows-msvc\release\deps\libgetopts-ae40a96de5f5d144.rlib
error: aborting due to previous error
For more information about this error, try `rustc --explain E0460`.
error: Could not compile `test`.
To learn more, run the command again with --verbose.
command did not execute successfully: "C:\\Users\\aberg\\work\\rust\\build\\x86_64-pc-windows-msvc\\stage0\\bin\\cargo.exe" "build" "--target" "x86_64-pc-windows-msvc" "-j" "12" "--release" "--manifest-path" "C:\\Users\\aberg\\work\\rust\\src/libtest/Cargo.toml" "--message-format" "json"
expected success, got: exit code: 101
failed to run: C:\Users\aberg\work\rust\build\bootstrap\debug\bootstrap test --stage 0 --no-doc src/libstd
Build completed unsuccessfully in 0:00:20
```
---
Since you wrote the linked PRs and might remember looking at related problems:
r? @alexcrichton
Get rid of the fake stack frame for reading from constants r? @RalfJung fixes the ice in rust-lang#53708 but still keeps around the wrong "non-exhaustive match" error cc @varkor
…lexcrichton Several changes to libunwind for SGX target Two fixes: * rust-lang#34978 bites again! * __rust_alloc are actually private symbols. Add new public versions. Also, these ones are `extern "C"`. Upstream changes (fortanix/llvm-project#2, fortanix/llvm-project#3): * b7357de Avoid too new relocation types being emitted * 0feefe5 Use new symbol names to call Rust allocator Fixes fortanix/rust-sgx#65
…=GuillaumeGomez rustdoc: fix ICE from loading proc-macro stubs Fixes rust-lang#55399 When trying to resolve a macro, rustdoc first tries to load it from the resolver to see whether it's a Macros 2.0 macro, so it can return that Def before looking for any other kind of macro. However, this becomes a problem when you try to load proc-macros: since you can't use a proc-macro inside its own crate, this lookup also fails when attempting to link to it. However, we have a hint that this lookup will fail: Macros which are actually `ProcMacroStub`s will fail the lookup, so we can use that information to skip loading the macro. Rustdoc will then happily check `resolve.all_macros`, which will return a usable Def that we can link to.
Add os::fortanix_sgx::ffi module This uses the same byte slice accessors that Unix has. The [ABI specifies](https://docs.rs/fortanix-sgx-abi/0.3.2/fortanix_sgx_abi/struct.ByteBuffer.html) byte slices.
…alexcrichton Don't export table by default in wasm Revert of rust-lang#53237 As per discussion here rustwasm/team#251
Add suggestion for incorrect field syntax. Fixes rust-lang#57684. This commit adds a suggestion when a `=` character is used when specifying the value of a field in a struct constructor incorrectly instead of a `:` character. r? @estebank
…tril Fix std::future::from_generator documentation This function takes a generator and wraps it in a future, not vice-versa.
Stabilize no_panic_pow This would close rust-lang#48320. I'm not sure if I've done this right, I've just changed attribute name to stable and set `since` to two minor versions above current stable since that seemed like what others were doing.
|
@bors r+ p=9 |
|
📌 Commit 5fa1016 has been approved by |
bors
added
the
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Jan 24, 2019
Rollup of 9 pull requests Successful merges: - #57380 (Fix Instant/Duration math precision & associativity on Windows) - #57606 (Get rid of the fake stack frame for reading from constants) - #57803 (Several changes to libunwind for SGX target) - #57846 (rustdoc: fix ICE from loading proc-macro stubs) - #57860 (Add os::fortanix_sgx::ffi module) - #57861 (Don't export table by default in wasm) - #57863 (Add suggestion for incorrect field syntax.) - #57867 (Fix std::future::from_generator documentation) - #57873 (Stabilize no_panic_pow) Failed merges: r? @ghost
|
☀️ Test successful - checks-travis, status-appveyor |
This was referenced Jan 25, 2019
|
☀️ Test successful - checks-travis, status-appveyor |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
Failed merges:
r? @ghost