std: Force `Instant::now()` to be monotonic
This commit is an attempt to force `Instant::now` to be monotonic
through any means possible. We tried relying on OS/hardware/clock
implementations, but those seem buggy enough that we can't rely on them
in practice. This commit implements the same hammer Firefox recently
implemented (noted in #56612) which is to just keep whatever the lastest
`Instant::now()` return value was in memory, returning that instead of
the OS looks like it's moving backwards.
Closes#48514Closes#49281
cc #51648
cc #56560Closes#56612Closes#56940
submodules: update clippy and rls
Fixes clippy toolstate
Changes:
````
Update to latest compiletest-rs release
add testcase for #3462
deps: bump rustc_tools_util version from 0.1.0 to 0.1.1 just in case...
rustc_tool_utils: fix failure to create proper non-repo version string when used in crates on crates.io, bump version
UI test cleanup: Extract ifs_same_cond tests
UI test cleanup: Extract for_kv_map lint tests
Fix test for rust-lang/rust#57250
Limit infinite_iter collect() check to known types
Some improvements to util documentation
Use hashset for name blacklist
Reformat random_state tests
Use node_id_to_type_opt instead of node_it_to_type in random_state
Check pattern equality while checking declaration equality
random_state lint
Use an FxHashSet for valid idents in documentation lint
Fix suggestion for unnecessary_ref lint
Update CONTRIBUTING.md for rustfix tests
Update .fixed files via update-references.sh
Run rustfix on first UI test
Use WIP branch for compiletest_rs
````
Also updates RLS and removes the patching of rustc_tool_utils from cargo.toml
RLS changes:
````
update clippy hash and rustc_tools_util and use rustc_tools_util from crates.io
Work around https://github.com/rust-lang/rust/pull/55937
Update Clippy... again
Update Clippy
Update clippy
````
r? @oli-obk
This reverts commit 68614265d312fc2cbe8a696f7dabb9416eb6f221, reversing
changes made to cae623c5ce12df8f237264d8f2c31fdaa664c382.
Should fix tools on windows.
Reopens#57014
This commit is an attempt to force `Instant::now` to be monotonic
through any means possible. We tried relying on OS/hardware/clock
implementations, but those seem buggy enough that we can't rely on them
in practice. This commit implements the same hammer Firefox recently
implemented (noted in #56612) which is to just keep whatever the lastest
`Instant::now()` return value was in memory, returning that instead of
the OS looks like it's moving backwards.
Closes#48514Closes#49281
cc #51648
cc #56560Closes#56612Closes#56940
Calculate privacy access only via query
Initially converted to query in a9f6babcda and then changed to respect dependencies 8281e883dd.
I did this as an effort to prune `CrateAnalysis` from librustc_save_analysis, with the only thing remaining being the glob map (`name` is unused, existing `crate_name` is exposed in the compiler passes, instead).
Since calculating the glob map is opt-in, it'd be great if we could calculate that on-demand. However, it seems that it'd require converting resolution to queries, which I'm not sure how to do yet.
In an effort to get rid of `CrateAnalysis` altogether, could we try unconditionally calculating the glob_map in the resolver, thus completely removing `CrateAnalysis` struct, and doing a perf run?
r? @nikomatsakis
cc @petrochenkov do you have any idea how/if at all could we querify the resolver? I've stumbled upon a comment that's ~3? years old at the moment, so I'm guessing things might have changed and it actually may be feasible now. fe0c10019d/src/librustc_driver/driver.rs (L589-L593)
Fix 'be be' constructs
I noticed a duplicated "be" somewhere in the code. A search for it
manifested a couple more locations with the same problem. This change
removes one of the "be"s.
Fix#56806 by using `delay_span_bug` in object safety layout sanity checks
It's possible that `is_object_safe` is called on a trait method that with an invalid receiver type. This caused an ICE in #56806, because `receiver_is_dispatchable` returns `true` for `self: Box<dyn Trait>`, which causes one of the layout sanity checks in object_safety.rs to fail. Replacing `bug!` with `delay_span_bug` solves this.
The fact that `receiver_is_dispatchable` returns `true` here could be considered a bug. It passes the check that the method implements, though: `Box<dyn Trait>` implements `DispatchFromDyn<Box<dyn Trait>>` because `dyn Trait` implements `Unsize<dyn Trait>`. It would be good to hear what @eddyb and @nikomatsakis think.
Note that I only added a test for the case encountered in #56806. I could not come up with a case that triggered an ICE from the other check, `bug!("receiver when Self = dyn Trait should be ScalarPair, found Scalar")`. There is no way, to my knowledge, that you can make `receiver_is_dispatchable` return true but still have a `Scalar` ABI when `Self = dyn Trait`.
One other case I encountered while debugging #56806 was that if you have a type parameter `T` that implements `Deref<Target=Self>` and `DispatchFromDyn<T>`, and use it as a method receiver, it will cause an ICE during `is_object_safe` because `T` has no layout ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=d9b7497b3be0ca8382fa7d9497263214)):
```rust
trait Trait<T: Deref<Target=Self> + DispatchFromDyn<T>> {
fn foo(self: T) -> dyn Trait<T>;
}
```
I don't intend to remove the ICE there because it is a pathological case, especially since there is no way to implement `DispatchFromDyn<T>` for `T` — the checks in typeck/coherence/builtin.rs do not allow that.
fixes#56806
r? @varkor
Add support for trait-objects without a principal
The hard-error version of #56481 - should be merged after we do something about the `traitobject` crate.
Fixes#33140.
Fixes#57057.
r? @nikomatsakis
Implement the Re-rebalance coherence RFC
This is the first time I touch anything in the compiler so just tell me if I got something wrong.
Big thanks to @sgrif for the pointers where to look for those things.
cc #55437
It's possible that `is_object_safe` is called on a trait that is ill-formed, and we shouldn't ICE unless there are no errors being raised. Using `delay_span_bug` solves this.
fixes#56806
Universes
This PR transitions the compiler to use **universes** instead of the **leak-check**. It is marked as [WIP] for a few reasons:
- The diagnostics at present are terrible =)
- This changes the behavior of coherence, regressing some things that used to compile
The goals of this PR at present are:
- To start getting some eyes on the code
- To do a crater run
- To see the full travis results (due to https://github.com/rust-lang/rust/issues/52452, I am not able to run the full test suite locally anymore at present)
The first few commits in the PR are changing how `evaluate` treats regions. We now track whether region comparisons occurred, reverting the "staticized" query approach that @arielb1 put in. The problem with "staticized" queries is that it relied on the leak-check to get higher-ranked things correct, and we are removing the leak-check in this PR series, so that caused problems.
You can see at the end a collection of test updates. Mostly we behave the same but with atrocious diagnostics, but there are a number of cases where we used to error and now no longer do, as well as single case where we used to **not** error but we now do (the coherence-subtyping change).
(Note: it would be possible to do a version of leak-check that propagates universe information and recover the old behavior. I am reluctant to do so because I'd like to leave us room to get more precise -- e.g., I want to eventually handle things like `exists<'a> { for<'b> { if ('a: 'b) { 'a: 'b } } }` which presently the leak-check cannot cope with etc. Also because it seems more consistent to me: most folks I've talked to expect the new behavior and are surprised to learn that binding sites were so significant before when it comes to coherence. One question is, though, to what extent are people relying on this in the wild?)
I noticed a duplicated "be" somewhere in the code. A search for it
manifested a couple more locations with the same problem. This change
removes one of the "be"s.
