Dylan DPC [Wed, 6 May 2020 11:22:05 +0000 (13:22 +0200)]
Rollup merge of #71510 - ssomers:btreemap_iter_intertwined, r=Mark-Simulacrum
Btreemap iter intertwined
3 commits:
1. Introduced benchmarks for `BTreeMap::iter()`. Benchmarks named `iter_20` were of the whole iteration process, so I renamed them. Also the benchmarks of `range` that I wrote earlier weren't very good. I included an (awkwardly named) one that compares `iter()` to `range(..)` on the same set, because the contrast is surprising:
```
name ns/iter
btree::map::range_unbounded_unbounded 28,176
btree::map::range_unbounded_vs_iter 89,369
```
Both dig up the same pair of leaf edges. `range(..)` also checks that some keys are correctly ordered, the only thing `iter()` does more is to copy the map's length.
2. Slightly refactoring the code to what I find more readable (not in chronological order of discovery), boosts performance:
```
>cargo-benchcmp.exe benchcmp a1 a2 --threshold 5
name a1 ns/iter a2 ns/iter diff ns/iter diff % speedup
btree::map::find_rand_100 18 17 -1 -5.56% x 1.06
btree::map::first_and_last_10k 64 71 7 10.94% x 0.90
btree::map::iter_0 2,939 2,209 -730 -24.84% x 1.33
btree::map::iter_1 6,845 2,696 -4,149 -60.61% x 2.54
btree::map::iter_100 8,556 3,672 -4,884 -57.08% x 2.33
btree::map::iter_10k 9,292 5,884 -3,408 -36.68% x 1.58
btree::map::iter_1m 10,268 6,510 -3,758 -36.60% x 1.58
btree::map::iteration_mut_100000 478,575 453,050 -25,525 -5.33% x 1.06
btree::map::range_unbounded_unbounded 28,176 36,169 7,993 28.37% x 0.78
btree::map::range_unbounded_vs_iter 89,369 38,290 -51,079 -57.16% x 2.33
btree::set::clone_100_and_remove_all 4,801 4,245 -556 -11.58% x 1.13
btree::set::clone_10k_and_remove_all 529,450 496,030 -33,420 -6.31% x 1.07
```
But you can tell from the `range_unbounded_*` lines that, despite an unwarranted, vengeful attack on the range_unbounded_unbounded benchmark, this change still doesn't allow `iter()` to catch up with `range(..)`.
3. I guess that `range(..)` copes so well because it intertwines the leftmost and rightmost descend towards leaf edges, doing the two root node accesses close together, perhaps exploiting a CPU's internal pipelining? So the third commit distils a version of `range_search` (which we can't use directly because of the `Ord` bound), and we get another boost:
```
cargo-benchcmp.exe benchcmp a2 a3 --threshold 5
name a2 ns/iter a3 ns/iter diff ns/iter diff % speedup
btree::map::first_and_last_100 40 43 3 7.50% x 0.93
btree::map::first_and_last_10k 71 64 -7 -9.86% x 1.11
btree::map::iter_0 2,209 1,719 -490 -22.18% x 1.29
btree::map::iter_1 2,696 2,205 -491 -18.21% x 1.22
btree::map::iter_100 3,672 2,943 -729 -19.85% x 1.25
btree::map::iter_10k 5,884 3,929 -1,955 -33.23% x 1.50
btree::map::iter_1m 6,510 5,532 -978 -15.02% x 1.18
btree::map::iteration_mut_100000 453,050 476,667 23,617 5.21% x 0.95
btree::map::range_included_excluded 405,075 371,297 -33,778 -8.34% x 1.09
btree::map::range_included_included 427,577 397,440 -30,137 -7.05% x 1.08
btree::map::range_unbounded_unbounded 36,169 28,175 -7,994 -22.10% x 1.28
btree::map::range_unbounded_vs_iter 38,290 30,838 -7,452 -19.46% x 1.24
```
But I think this is just fake news from the microbenchmarking media. `iter()` is still trying to catch up with `range(..)`. And we can sure do without another function. So I would skip this 3rd commit.
bors [Wed, 6 May 2020 07:03:31 +0000 (07:03 +0000)]
Auto merge of #69464 - Marwes:detach_undo_log, r=nikomatsakis
perf: Unify the undo log of all snapshot types
Extracted from #69218 and extended to all the current snapshot types.
Since snapshotting is such a frequent action in the compiler and many of the scopes execute so little work, the act of creating the snapshot and rolling back empty/small snapshots end up showing in perf. By unifying all the logs into one the creation of snapshots becomes significantly cheaper at the cost of some complexity when combining the log with the specific data structures that are being mutated.
Depends on https://github.com/rust-lang-nursery/ena/pull/29
bors [Tue, 5 May 2020 23:52:56 +0000 (23:52 +0000)]
Auto merge of #71875 - Xanewok:update-rls, r=tmandry
Update RLS
In addition to fixing the toolstate, this also changes the default
compilation model to the out-of-process one, which should hopefully
target considerable memory usage for long-running instances of the RLS.
In addition to fixing the toolstate, this also changes the default
compilation model to the out-of-process one, which should hopefully
target considerable memory usage for long-running instances of the RLS.
bors [Tue, 5 May 2020 11:05:18 +0000 (11:05 +0000)]
Auto merge of #71916 - Dylan-DPC:rollup-luj7zx3, r=Dylan-DPC
Rollup of 4 pull requests
Successful merges:
- #69984 (Add Option to Force Unwind Tables)
- #71830 (Remove clippy from some leftover lists of "possibly failing" tools)
- #71894 (Suggest removing semicolon in last expression only if it's type is known)
- #71897 (Improve docs for embed-bitcode and linker-plugin-lto)
Dylan DPC [Tue, 5 May 2020 10:55:09 +0000 (12:55 +0200)]
Rollup merge of #71830 - oli-obk:subrepo_funness, r=Mark-Simulacrum
Remove clippy from some leftover lists of "possibly failing" tools
https://github.com/rust-lang/rust/pull/70655 successfully made clippy get built and tested on CI on every merge, but the lack of emitted toolstate info caused the toolstate to get updated to test-fail. We should remove clippy entirely from toolstate, as it now is always test-pass.
The changes made in this PR reflect what we do for `rustdoc`, which is our preexisting tool that is gated on CI.
Dylan DPC [Tue, 5 May 2020 10:55:08 +0000 (12:55 +0200)]
Rollup merge of #69984 - lenary:lenary/force-uwtables, r=hanna-kruppe
Add Option to Force Unwind Tables
When panic != unwind, `nounwind` is added to all functions for a target.
This can cause issues when a panic happens with RUST_BACKTRACE=1, as
there needs to be a way to reconstruct the backtrace. There are three
possible sources of this information: forcing frame pointers (for which
an option exists already), debug info (for which an option exists), or
unwind tables.
Especially for embedded devices, forcing frame pointers can have code
size overheads (RISC-V sees ~10% overheads, ARM sees ~2-3% overheads).
In production code, it can be the case that debug info is not kept, so it is useful
to provide this third option, unwind tables, that users can use to
reconstruct the call stack. Reconstructing this stack is harder than
with frame pointers, but it is still possible.
---
This came up in discussion on #69890, and turned out to be a fairly simple addition.
By merging the undo_log of all structures part of the snapshot the cost
of creating a snapshot becomes much cheaper. Since snapshots with no or
few changes are so frequent this ends up mattering more than the slight
overhead of dispatching on the variants that map to each field.
Dylan DPC [Mon, 4 May 2020 23:49:44 +0000 (01:49 +0200)]
Rollup merge of #71881 - IsaacWoods:master, r=petrochenkov
Correctly handle UEFI targets as Windows-like when emitting sections for LLVM bitcode
This handles UEFI handles when emitting inline assembly for sections containing LLVM bitcode. See details in #71880. I have locally confirmed that this change fixes compilation of projects using the `x86_64-unknown-uefi` target compiling with `cargo-xbuild`, but I am not very familiar with LLVM bitcode so this may not be the correct approach.
r? @alexcrichton as they wrote the initial LLVM bitcode emitting code?
Dylan DPC [Mon, 4 May 2020 23:49:43 +0000 (01:49 +0200)]
Rollup merge of #71878 - main--:patch-2, r=Amanieu
Add remove_current_as_list to LinkedList's CursorMut
The `remove_current` method only returns the inner `T` and deallocates the list node. This is unnecessary for move operations, where the element is going to be linked back into this (or even a different) `LinkedList`. The `remove_current_as_list` method avoids this by returning the unlinked list node as a new single-element `LinkedList` structure.
Dylan DPC [Mon, 4 May 2020 23:49:41 +0000 (01:49 +0200)]
Rollup merge of #71845 - steveklabnik:add-const-examples, r=dtolnay
Add const examples
I only added them to `std::f32` to get feedback on this approach before adding the other constants.
When looking at https://github.com/rust-lang/rust/pull/68952, I found the docs a little confusing. Unless you're intimately aware of what's going on here, I don't think it's super clear what is deprecated and what you're supposed to do instead. I think short examples really clarify what's meant here, so that's what I did.
bors [Mon, 4 May 2020 17:34:51 +0000 (17:34 +0000)]
Auto merge of #71879 - Dylan-DPC:rollup-n05awny, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #71038 (forbid `dyn Trait` in patterns)
- #71697 (Added MIR constant propagation of Scalars into function call arguments)
- #71773 (doc: misc rustdoc things)
- #71810 (Do not try to find binop method on RHS `TyErr`)
- #71877 (Use f64 in f64 examples)
Dylan DPC [Mon, 4 May 2020 14:15:28 +0000 (16:15 +0200)]
Rollup merge of #71697 - felix91gr:new_prop_into_fn_call, r=wesleywiser
Added MIR constant propagation of Scalars into function call arguments
Now for the function call arguments!
Caveats:
1. It's only being enabled at `mir-opt-2` or higher, because currently codegen gives performance regressions with this optimization.
2. Only propagates Scalars. Tuples and references (references are `Indirect`, right??) are not being propagated into as of this PR.
3. Maybe more tests would be nice?
4. I need (shamefully) to ask @wesleywiser to write in his words (or explain to me, and then I can write it down) why we want to ignore propagation into `ScalarPairs` and `Indirect` arguments.
bors [Mon, 4 May 2020 14:14:55 +0000 (14:14 +0000)]
Auto merge of #71754 - alexcrichton:no-bitcode-in-cache, r=nnethercote
Don't copy bytecode files into the incr. comp. cache.
It's no longer necessary now that bitcode is embedded into object files.
This change meant that `WorkProductFileKind::Bytecode` is no longer
necessary, which means that type is no longer necessary, which allowed
several places in the code to become simpler.
This commit was written by @nnethercote in https://github.com/rust-lang/rust/pull/70458 but that didn't land. In the meantime though we managed to land it in https://github.com/rust-lang/rust/pull/71528 and that doesn't seem to be causing too many fires, so I'm re-sending this patch!
main() [Mon, 4 May 2020 13:53:02 +0000 (15:53 +0200)]
Add remove_current_as_list to LinkedList's CursorMut
The `remove_current` method only returns the inner `T` and deallocates the list node. This is unnecessary for move operations, where the element is going to be linked back into this (or even a different) `LinkedList`. The `remove_current_as_list` method avoids this by returning the unlinked list node as a new single-element `LinkedList` structure .
Sam Elliott [Mon, 4 May 2020 11:08:35 +0000 (12:08 +0100)]
Add Option to Force Unwind Tables
When panic != unwind, `nounwind` is added to all functions for a target.
This can cause issues when a panic happens with RUST_BACKTRACE=1, as
there needs to be a way to reconstruct the backtrace. There are three
possible sources of this information: forcing frame pointers (for which
an option exists already), debug info (for which an option exists), or
unwind tables.
Especially for embedded devices, forcing frame pointers can have code
size overheads (RISC-V sees ~10% overheads, ARM sees ~2-3% overheads).
In code, it can be the case that debug info is not kept, so it is useful
to provide this third option, unwind tables, that users can use to
reconstruct the call stack. Reconstructing this stack is harder than
with frame pointers, but it is still possible.
This commit adds a compiler option which allows a user to force the
addition of unwind tables. Unwind tables cannot be disabled on targets
that require them for correctness, or when using `-C panic=unwind`.
bors [Mon, 4 May 2020 06:32:49 +0000 (06:32 +0000)]
Auto merge of #71108 - estebank:suggest-proj-type-mismatch-constraint, r=oli-obk
On type mismatch involving associated type, suggest constraint
When an associated type is found when a specific type was expected, if
possible provide a structured suggestion constraining the associated
type in a bound.
```
error[E0271]: type mismatch resolving `<T as Foo>::Y == i32`
--> $DIR/associated-types-multiple-types-one-trait.rs:13:5
|
LL | want_y(t);
| ^^^^^^ expected `i32`, found associated type
...
LL | fn want_y<T:Foo<Y=i32>>(t: &T) { }
| ----- required by this bound in `want_y`
|
= note: expected type `i32`
found associated type `<T as Foo>::Y`
help: consider constraining the associated type `<T as Foo>::Y` to `i32`
|
LL | fn have_x_want_y<T:Foo<X=u32, Y = i32>>(t: &T)
| ^^^^^^^^^
```
```
error[E0308]: mismatched types
--> $DIR/trait-with-missing-associated-type-restriction.rs:12:9
|
LL | qux(x.func())
| ^^^^^^^^ expected `usize`, found associated type
|
= note: expected type `usize`
found associated type `<impl Trait as Trait>::A`
help: consider constraining the associated type `<impl Trait as Trait>::A` to `usize`
|
LL | fn foo(x: impl Trait<A = usize>) {
| ^^^^^^^^^^
```
bors [Mon, 4 May 2020 01:48:07 +0000 (01:48 +0000)]
Auto merge of #71866 - Dylan-DPC:rollup-g9xqc8k, r=Dylan-DPC
Rollup of 4 pull requests
Successful merges:
- #71645 (Direct contributors to try stage 0 rustdoc first)
- #71801 (Correctly check comparison operator in MIR typeck)
- #71844 (List Clippy as a subtree, instead of a submodule)
- #71864 (Update link in contributing.md)
Dylan DPC [Mon, 4 May 2020 01:14:57 +0000 (03:14 +0200)]
Rollup merge of #71801 - matthewjasper:operator-subtyping, r=varkor
Correctly check comparison operator in MIR typeck
The subtyping for comparisons between pointers was reversed in MIR typeck.
There also wasn't a check that comparisons between numeric types had matching types.
Dylan DPC [Mon, 4 May 2020 01:14:53 +0000 (03:14 +0200)]
Rollup merge of #71645 - ecstatic-morse:readme-build-doc, r=Mark-Simulacrum
Direct contributors to try stage 0 rustdoc first
After #71458, `./x.py doc --stage 0 src/libstd` is (empirically) able to build the standard library docs using the `rustdoc` packaged with the bootstrap compiler. This means that new contributors don't need to build the compiler to locally inspect small documentation fixes. This was a roadblock for me when I first started contributing to rust and something that still regularly annoys people. We should recommend that contributors give bootstrap `rustdoc` a try before building the whole compiler.
bors [Sun, 3 May 2020 22:54:55 +0000 (22:54 +0000)]
Auto merge of #71631 - RalfJung:miri-unleash-the-gates, r=oli-obk
Miri: unleash all feature gates
IMO it is silly to unleash features that do not even have a feature gate yet, but not unleash features that do. The only thing this achieves is making unleashed mode annoying to use as we have to figure out the feature flags to enable (and not always do the error messages say what that flag is).
Given that the point of `-Z unleash-the-miri-inside-of-you` is to debug the Miri internals, I see no good reason for this extra hurdle. I cannot imagine a situation where we'd use that flag, realize the program also requires some feature gate, and then be like "oh I guess if this feature is unstable I will do something else". Instead, we'll always just add that flag to the code as well, so requiring the flag achieves nothing.
bors [Sun, 3 May 2020 19:46:17 +0000 (19:46 +0000)]
Auto merge of #71006 - ecstatic-morse:dataflow-bidi, r=ecstatic-morse
Use existing framework for backward dataflow analyses
This PR adds support for backward analyses to the dataflow framework and adds a new live variable analysis (based on the existing one in `librustc_mir/util/liveness.rs`). By adding these to the framework instead of having a separate API, all newly implemented backward dataflow analyses get cursors/visitors, `rustc_peek` tests, and graphviz visualizations for free. In the near-term, this makes it much easier to implement global dead-store elimination, and I believe that this will enable even more MIR optimizations in the future.
This PR makes many changes to the dataflow API, since some concepts and terminology only make sense in forward dataflow. Below is a list of the important changes.
- ~~`entry_set` -> `fixpoint` (the fixpoint for backward dataflow problems is after the block's terminator)~~
- `seek_{before,after}` -> `seek_{before,after}_primary_effect` (the unprefixed dataflow effect is now referred to as the "primary" effect instead of the "after" effect. The "before" effect remains the same, although I considered changing it to the "antecedent" effect. In both backward and forward dataflow, the "before" effect is applied prior to the "primary" effect. I feel very strongly that this is the correct choice, as it means consumers don't have to switch between `seek_before` and `seek_after` based on the direction of their analysis.
- `seek_after_assume_call_returns` is now gone. Users can use `ResultsCursor::apply_custom_effect` to emulate it.
- `visit_{statement,terminator}_exit` -> `visit_{statement,terminator}_after_primary_effect`
- `visit_{statement,terminator}` -> `visit_{statement,terminator}_before_primary_effect`
Implementing this also required refactoring the dataflow cursor implementation so it could work in both directions. This is a large percentage of the diff, since the cursor code is rather complex. The fact that the cursor is exhaustively tested in both directions should reassure whomever is unlucky enough to review this :rofl:.
In order to avoid computing the reverse CFG for forward dataflow analyses, I've added some hacks to the existing `mir::BodyAndCache` interface. I've requested changes to this interface that would let me implement this more efficiently.
r? @eddyb (feel free to reassign)
cc @rust-lang/wg-mir-opt
bors [Sun, 3 May 2020 16:38:41 +0000 (16:38 +0000)]
Auto merge of #71853 - Dylan-DPC:rollup-4qi6ry9, r=Dylan-DPC
Rollup of 4 pull requests
Successful merges:
- #71398 (Add `RefCell::take`)
- #71663 (Fix exceeding bitshifts not emitting for assoc. consts (properly this time, I swear!))
- #71726 (Suggest deref when coercing `ty::Ref` to `ty::RawPtr` with arbitrary mutability)
- #71808 (Add long error explanation for E0539)
Dylan DPC [Sun, 3 May 2020 16:34:50 +0000 (18:34 +0200)]
Rollup merge of #71808 - unexge:long-err-expl-for-e0539, r=GuillaumeGomez
Add long error explanation for E0539
since this error is similar to [E0551](https://github.com/rust-lang/rust/blob/master/src/librustc_error_codes/error_codes/E0551.md) most of the content was copied from it. part of #61137.
Dylan DPC [Sun, 3 May 2020 16:34:46 +0000 (18:34 +0200)]
Rollup merge of #71726 - ldm0:ref2ptr, r=oli-obk
Suggest deref when coercing `ty::Ref` to `ty::RawPtr` with arbitrary mutability
Fixes #71676
1. Implement dereference suggestion when coercing `ty::Ref` to `ty::RawPtr` with arbitrary mutability.
2. Extract the dereference steps into `deref_steps()`, which removes all the `use` and `pub` noise introduced by last PR #71540, and makes the code more readable.
3. Use the `remove_prefix()` closure which makes the prefix removal more readable.
4. Introduce `Applicability` as a return value of `check_ref` to suggest `Applicability::Unspecified` suggestion.
**Special**: I found it is not possible to genereate `Applicability::MachineApplicable` suggestion for situation like this:
```rust
use std::ops::Deref;
use std::ops::DerefMut;
struct Bar(u8);
struct Foo(Bar);
struct Emm(Foo);
impl Deref for Bar{
type Target = u8;
fn deref(&self) -> &Self::Target {
&self.0
}
}
impl Deref for Foo {
type Target = Bar;
fn deref(&self) -> &Self::Target {
&self.0
}
}
impl Deref for Emm {
type Target = Foo;
fn deref(&self) -> &Self::Target {
&self.0
}
}
impl DerefMut for Bar{
fn deref_mut(&mut self) -> &mut Self::Target {
&mut self.0
}
}
impl DerefMut for Foo {
fn deref_mut(&mut self) -> &mut Self::Target {
&mut self.0
}
}
impl DerefMut for Emm {
fn deref_mut(&mut self) -> &mut Self::Target {
&mut self.0
}
}
fn main() {
let a = Emm(Foo(Bar(0)));
let _: *mut u8 = &a; //~ ERROR mismatched types
}
```
We may suggest `&mut ***a` here, but the `a` is not declared as mutable variable. And also when processing HIR, it's not possible to check if `a` is declared as a mutable variable (currently we do borrow checking with MIR). So we cannot ensure that suggestion when coercing immutable reference to mutable pointer is always machine applicable. Therefore I added a `Applicability` return value in `check_ref()`. And move the `immutable reference -> mutable pointer` situation into a sperate test file without `run-rustfix`. (It seems that `run-rustfix` will also adopt `Applicability::Unspecified` suggestion, which is strange)
Dylan DPC [Sun, 3 May 2020 16:34:41 +0000 (18:34 +0200)]
Rollup merge of #71663 - jumbatm:caller-handles-validation-error, r=RalfJung
Fix exceeding bitshifts not emitting for assoc. consts (properly this time, I swear!)
Fixes #69021 and fixes #71353.
As described in https://github.com/rust-lang/rust/issues/71353#issuecomment-617901923, this PR:
- adds a variant of `try_validation!` called `try_validation_pat!` that allows specific failures to be turned into validation failures (but returns the rest, unchanged), and
- allows `InvalidProgram` to be returned out of validation