The current code in `SipHasher128::short_write` is inefficient. It uses
`u8to64_le` (which is complex and slow) to extract just the right number of
bytes of the input into a u64 and pad the result with zeroes. It then
left-shifts that value in order to bitwise-OR it with `self.tail`.
For example, imagine we have a u32 input 0xIIHH_GGFF and only need three bytes
to fill up `self.tail`. The current code uses `u8to64_le` to construct
0x0000_0000_00HH_GGFF, which is just 0xIIHH_GGFF with the 0xII removed and
zero-extended to a u64. The code then left-shifts that value by five bytes --
discarding the 0x00 byte that replaced the 0xII byte! -- to give
0xHHGG_FF00_0000_0000. It then then ORs that value with self.tail.
There's a much simpler way to do it: zero-extend to u64 first, then left shift.
E.g. 0xIIHH_GGFF is zero-extended to 0x0000_0000_IIHH_GGFF, and then
left-shifted to 0xHHGG_FF00_0000_0000. We don't have to take time to exclude
the unneeded 0xII byte, because it just gets shifted out anyway! It also avoids
multiple occurrences of `unsafe`.
There's a similar story with the setting of `self.tail` at the method's end.
The current code uses `u8to64_le` to extract the remaining part of the input,
but the same effect can be achieved more quickly with a right shift on the
zero-extended input.
All that works on little-endian. It doesn't work for big-endian, but we
can just do a `to_le` before calling `short_write` and then it works.
This commit changes `SipHasher128` to use the simpler shift-based approach. The
code is also smaller, which means that `short_write` is now inlined where
previously it wasn't, which makes things faster again. This gives big
speed-ups for all incremental builds, especially "baseline" incremental
builds.
Dylan DPC [Mon, 10 Feb 2020 00:54:21 +0000 (01:54 +0100)]
Rollup merge of #69005 - ecstatic-morse:unified-dataflow-graphviz, r=wesleywiser
Small graphviz improvements for the new dataflow framework
Split out from #68241. This prints the correct effect diff for each line (the before-effect and the after-effect) and makes marginal improvements to the graphviz output for the new dataflow framework including using monospaced font and better line breaking. This will only be useful when #68241 is merged and the graphviz output changes from this:
Dylan DPC [Mon, 10 Feb 2020 00:54:17 +0000 (01:54 +0100)]
Rollup merge of #68966 - jonas-schievink:coherence-perf, r=varkor
Improve performance of coherence checks
The biggest perf improvement in here is expected to come from the removal of the remaining #43355 warning code since that effectively runs the expensive parts of coherence *twice*, which can even be visualized by obtaining a flamegraph:
Dylan DPC [Mon, 10 Feb 2020 00:54:15 +0000 (01:54 +0100)]
Rollup merge of #68694 - nnethercote:reduce-RefCells-in-InferCtxt, r=varkor
Reduce the number of `RefCell`s in `InferCtxt`.
`InferCtxt` contains six structures within `RefCell`s. Every time we
create and dispose of (commit or rollback) a snapshot we have to
`borrow_mut` each one of them.
This commit moves the six structures under a single `RefCell`, which
gives significant speed-ups by reducing the number of `borrow_mut`
calls. To avoid runtime errors I had to reduce the lifetimes of dynamic
borrows in a couple of places.
bors [Sun, 9 Feb 2020 22:13:05 +0000 (22:13 +0000)]
Auto merge of #67665 - Patryk27:master, r=zackmdavis
Improve reporting errors and suggestions for trait bounds
Fix #66802
- When printing errors for unsized function parameter, properly point at the parameter instead of function's body.
- Improve `consider further restricting this bound` (and related) messages by separating human-oriented hints from the machine-oriented ones.
`InferCtxt` contains six structures within `RefCell`s. Every time we
create and dispose of (commit or rollback) a snapshot we have to
`borrow_mut` each one of them.
This commit moves the six structures under a single `RefCell`, which
gives significant speed-ups by reducing the number of `borrow_mut`
calls. To avoid runtime errors I had to reduce the lifetimes of dynamic
borrows in a couple of places.
bors [Sun, 9 Feb 2020 18:44:39 +0000 (18:44 +0000)]
Auto merge of #69004 - jonas-schievink:rollup-z2ymler, r=jonas-schievink
Rollup of 5 pull requests
Successful merges:
- #68738 (Derive Clone + Eq for std::string::FromUtf8Error)
- #68742 (implement AsMut<str> for String)
- #68881 (rustc_codegen_llvm: always set AlwaysPreserve on all debuginfo variables)
- #68911 (Speed up the inherent impl overlap check)
- #68913 (Pretty-print generic params and where clauses on associated types)
Dylan MacKenzie [Tue, 21 Jan 2020 02:36:54 +0000 (18:36 -0800)]
Print `after` effect in default graphviz formatter
Now the line for each statement will show the diff resulting from the
combination of `before_statement_effect` and `statement_effect`. It's
still possible to observe each in isolation via
`borrowck_graphviz_format = "two_phase"`.
Jonas Schievink [Sun, 9 Feb 2020 17:23:31 +0000 (18:23 +0100)]
Rollup merge of #68881 - eddyb:always-preserve-dbg-vars, r=nagisa
rustc_codegen_llvm: always set AlwaysPreserve on all debuginfo variables
Making this depend on the optimization level appears to have been a copy-paste mistake (other LLVM functions called in this module also take a `bool` argument, but there it means something unrelated).
Also see https://github.com/rust-lang/rust/pull/8855#discussion_r374392128.
I don't believe we have any reason to let LLVM omit user variables from DWARF, and we were already setting this to `true` when LLVM *could* optimize them away, so this PR should have no effect anyway.
r? @michaelwoerister or @nagisa cc @hanna-kruppe @nikomatsakis
bors [Sun, 9 Feb 2020 15:24:50 +0000 (15:24 +0000)]
Auto merge of #68623 - Zoxc:lld, r=Mark-Simulacrum
Add an option to use LLD to link the compiler on Windows platforms
Based on https://github.com/rust-lang/rust/pull/68609.
Using LLD is good way to improve compile times on Windows since `link.exe` is quite slow. The time for `x.py build --stage 1 src/libtest` goes from 0:12:00 to 0:08:29. Compile time for `rustc_driver` goes from 226.34s to 18.5s. `rustc_macros` goes from 28.69s to 7.7s. The size of `rustc_driver` is also reduced from 83.3 MB to 78.7 MB.
bors [Sun, 9 Feb 2020 10:20:46 +0000 (10:20 +0000)]
Auto merge of #68975 - Dylan-DPC:rollup-jzab8oh, r=Dylan-DPC
Rollup of 7 pull requests
Successful merges:
- #68718 (Move `rustc_hir::def_id` to `rustc_span::def_id`)
- #68834 (Fix and test implementation of BTreeMap's first/last_entry, pop_first/last)
- #68857 (perf: Reduce Vec allocations in normalization by passing &mut Vec)
- #68918 (Don't use the word "unwrap" to describe "unwrap" methods)
- #68946 (Mark several functions and methods in core::cmp as #[must_use])
- #68958 (Clean up E0277 and E0282 explanations)
- #68960 (codegen: misc cleanups around debuginfo scopes and locations.)
bors [Sun, 9 Feb 2020 07:11:56 +0000 (07:11 +0000)]
Auto merge of #68689 - estebank:where-clause-sugg-missing-fn, r=varkor
When suggesting associated fn with type parameters, include in the structured suggestion
Address #50734.
```
error[E0046]: not all trait items implemented, missing: `foo`, `bar`, `baz`
--> file.rs:14:1
|
14 | impl TraitA<()> for S {
| ^^^^^^^^^^^^^^^^^^^^^ missing `foo`, `bar`, `baz` in implementation
|
= help: implement the missing item: `fn foo<T>(_: T) -> Self where T: TraitB, TraitB::Item = A { unimplemented!() }`
= help: implement the missing item: `fn bar<T>(_: T) -> Self { unimplemented!() }`
= help: implement the missing item: `fn baz<T>(_: T) -> Self where T: TraitB, <T as TraitB>::Item: std::marker::Copy { unimplemented!() }`
```
It doesn't work well for associated types with `ty::Predicate::Projection`s as we need to resugar `T: Trait, Trait::Assoc = K` → `T: Trait<Assoc = K>`.
bors [Sun, 9 Feb 2020 04:01:28 +0000 (04:01 +0000)]
Auto merge of #68376 - Centril:move-ref-patterns, r=matthewjasper
Initial implementation of `#![feature(move_ref_pattern)]`
Following up on #45600, under the gate `#![feature(move_ref_pattern)]`, `(ref x, mut y)` is allowed subject to restrictions necessary for soundness. The match checking implementation and tests for `#![feature(bindings_after_at)]` is also adjusted as necessary.
Dylan DPC [Sat, 8 Feb 2020 23:53:55 +0000 (00:53 +0100)]
Rollup merge of #68918 - brson:unwrapdoc, r=Dylan-DPC
Don't use the word "unwrap" to describe "unwrap" methods
It's tautological, and "unwrap" is essentially Rust-specific jargon.
I was teaching a newbie some Rust, and doing the usual hand-waving about error handling using unwrap. They asked what 'unwrap' means. I said look it up in the docs. The docs read (paraphrased) "unwrap unwraps". I was embarrassed.
This changes all the Option/Result functions with unwrapping behavior to use a variation on a single description:
> "Returns the contained `Some/Ok` value [or ...]."
It also renames the closure of `Result::unwrap_or_else` to `default` for consistency with `Option`, and perhaps makes a few other small tweaks.
bors [Sat, 8 Feb 2020 21:28:05 +0000 (21:28 +0000)]
Auto merge of #68802 - eddyb:debuginfo-there-can-only-be-one-arg, r=nagisa
rustc_codegen_ssa: don't treat inlined variables as debuginfo arguments.
Fixes #67586 by limiting `ArgumentVariable` special-casing to `VarDebugInfo` entries that are in `OUTERMOST_SOURCE_SCOPE`, i.e. the function's own argument scope.
That excludes `VarDebugInfo` from inlined callees, which can also point to the caller's argument locals.
This is a snippet from the optimized MIR (including inlining) of the testcase:
```rust
fn foo(_1: usize) -> usize {
debug bar => _1; // in scope 0 at ./example.rs:2:12: 2:15
let mut _0: usize; // return place in scope 0 at ./example.rs:2:27: 2:32
scope 1 {
debug x => _1; // in scope 1 at /rustc/9ed29b6ff6aa2e048b09c27af8f62ee3040bdb37/src/libcore/convert/mod.rs:106:26: 106:27
}
```
`scope 1` is from inlining the `identity` call, and `debug x => _1;` comes from the body of `core::convert::identity`, so they are now ignored for the purposes of determining the `ArgumentVariable` debuginfo associated to `_1`.
bors [Sat, 8 Feb 2020 13:02:21 +0000 (13:02 +0000)]
Auto merge of #68443 - eddyb:abi-compat-enum, r=nagisa
rustc_target: treat enum variants like union members, in call ABIs.
Fixes #68190, by handling non-C-like `enum`s as-if they were an `union` of `struct`s, in call ABIs.
Tests were provided by @sw17ch, from theirs and @bitwalker's original examples.
John VanEnk [Wed, 22 Jan 2020 06:26:13 +0000 (22:26 -0800)]
Two test cases where Rust calls C using enums by value
One calls into C functions passing non-c-like enumerations by
value. The other calls into C expecting non-C-like enumerations as
returns.
These test cases are based on the tests provided by @bitwalker on
issue #68190. The original tests were provided at:
https://github.com/bitwalker/rust_non_c_like_enums_issue/tree/2688d5c672bd4e289085fcdf1c6110e99e7e8ab1
bors [Sat, 8 Feb 2020 03:46:56 +0000 (03:46 +0000)]
Auto merge of #68358 - matthewjasper:spec-fix, r=nikomatsakis
Remove some unsound specializations
This removes the unsound and exploitable specializations in the standard library
* The `PartialEq` and `Hash` implementations for `RangeInclusive` are changed to avoid specialization.
* The `PartialOrd` specialization for slices now specializes on a limited set of concrete types.
* Added some tests for the soundness problems.