Auto merge of #51855 - Eh2406:i51821, r=nikomatsakis
A fix for 51821
This dedupe the vec of `OutlivesConstraint` using a `FxHashSet<(RegionVid, RegionVid)>` it alsow adds a `struct ConstraintSet` to encapsulate/ensure this behavere.
Auto merge of #51882 - varkor:check-type_dependent_defs, r=estebank
Always check type_dependent_defs
Directly indexing into `type_dependent_defs` has caused multiple ICEs in the past (https://github.com/rust-lang/rust/issues/46771, https://github.com/rust-lang/rust/issues/49241, etc.) and is almost certainly responsible for #51798 too. This PR ensures we always check `type_dependent_defs` first, which should prevent any more of these (or at least make them easier to track down).
Mark Simulacrum [Thu, 28 Jun 2018 16:06:42 +0000 (10:06 -0600)]
Notice non-toplevel dll dependencies in rustbuild
Previously Cargo would hardlink all the dependencies into the "root" as
foo.dll and the `toplevel` array would get populated with these, but
that's no longer the case. Instead, cargo will only do this for the
final artifacts/final libraries.
Rustbuild is updated to continue looping through the artifacts mentioned
instead of early-returning. This should fix the bug.
@alexcrichton found the cause of this and suggested this fix.
bors [Fri, 29 Jun 2018 16:48:57 +0000 (16:48 +0000)]
Auto merge of #51569 - SimonSapin:liballoc, r=sfackler
Make the public API of the alloc crate a subset of std
This only affects **unstable** APIs.
I plan to submit an RFC proposing to stabilize the crate. The reason it isn’t stable yet (https://github.com/rust-lang/rust/issues/27783) is in case we end up merging the standard library crates into one. However the `core` crate is already stable, so if that happens we’ll need to keep it working somehow (likely by making replacing its contents by `pub use` items). We can do the same for `alloc`. This PR will hopefully make this easier, but even if that doesn’t happen consistency with `std` seems good.
bors [Fri, 29 Jun 2018 12:40:12 +0000 (12:40 +0000)]
Auto merge of #51729 - matthewjasper:move-errors, r=nikomatsakis
[NLL] Better move errors
Make a number of changes to improve the quality of NLL cannot move errors.
* Group errors that occur in the same `match` with the same cause.
* Suggest `ref`, `&` or removing `*` to avoid the move.
* Show the place being matched on.
Differences from AST borrowck:
* `&` is suggested over `ref` when matching on a place that can't be moved from.
* Removing `*` is suggested instead of adding `&` when applicable.
* Sub-pattern spans aren't used, this would probably need Spans on Places.
bors [Fri, 29 Jun 2018 09:42:40 +0000 (09:42 +0000)]
Auto merge of #50526 - moxian:just-fix, r=alexcrichton
Add a fallback for stacktrace printing for older Windows versions.
Some time ago we switched stack inspection functions of dbghelp.dll to their newer alternatives that also capture inlined context.
Unfortunately, said new alternatives are not present in older dbghelp.dll versions.
In particular Windows 7 at the time of writing has dbghelp.dll version 6.1.7601 from 2010, that lacks StackWalkEx and friends.
Tested on my Windows 7 - both msvc and gnu versions produce a readable stacktrace.
bors [Fri, 29 Jun 2018 07:34:13 +0000 (07:34 +0000)]
Auto merge of #51290 - Pslydhh:master, r=alexcrichton
park/park_timeout: prohibit spurious wakeups in next park
<pre><code>
// The implementation currently uses the trivial strategy of a Mutex+Condvar
// with wakeup flag, which does not actually allow spurious wakeups.
</pre></code>
Because does not actually allow spurious wakeups.
so we have let thread.inner.cvar.wait(m) in the loop to prohibit spurious wakeups.
but if notified after we locked, this notification doesn't be consumed, it return, the next park will consume this notification...this is also 'spurious wakeup' case, 'one unpark() wakeups two park()'.
We should improve this situation:
`thread.inner.state.store(EMPTY, SeqCst);`
bors [Fri, 29 Jun 2018 04:09:02 +0000 (04:09 +0000)]
Auto merge of #50357 - seanmonstar:arc-weak-null, r=KodrAus
Arc: remove unused allocation from Weak::new()
It seems non-obvious that calling `Weak::new()` actually allocates space for the entire size of `T`, even though you can **never** access that data from such a constructed weak pointer. Besides that, if someone were to create many `Weak:new()`s, they could be unknowingly wasting a bunch of memory.
This change makes it so that `Weak::new()` allocates no memory at all. Instead, it is created with a null pointer. The only things done with a `Weak` are trying to upgrade, cloning, and dropping, meaning there are very few places that the code actually needs to check if the pointer is null.
- `IdxSetBuf` derefs to `IdxSet`.
- `IdxSetBuf` implements `Clone`, and therefore has a provided `clone_from`
method, which does allocation and so is expensive.
- `IdxSet` has a `clone_from` method that is non-allocating and therefore
cheap, but this method is not from the `Clone` trait.
As a result, if you have an `IdxSetBuf` called `b`, if you call
`b.clone_from(b2)` you'll get the expensive `IdxSetBuf` method, but if you call
`(*b).clone_from(b2)` you'll get the cheap `IdxSetBuf` method.
`liveness_of_locals()` does the former, presumably unintentionally, and
therefore does lots of unnecessary allocations.
Having a `clone_from` method that isn't from the `Clone` trait is a bad idea in
general, so this patch renames it as `overwrite`. This avoids the unnecessary
allocations in `liveness_of_locals()`, speeding up most NLL benchmarks, the
best by 1.5%. It also means that calls of the form `(*b).clone_from(b2)` can be
rewritten as `b.overwrite(b2)`.
Mark Rousskov [Thu, 28 Jun 2018 22:07:12 +0000 (16:07 -0600)]
Rollup merge of #51765 - jonas-schievink:patch-1, r=KodrAus
Use assert_eq! in copy_from_slice
This will print both lengths when the assertion fails instead of just saying that they're different.
Output of current stable and nightly (modulo the exact line number):
```
thread 'main' panicked at 'destination and source slices have different lengths', libcore/slice/mod.rs:1645:9
```
Output after this PR:
```
thread 'main' panicked at 'assertion failed: `(left == right)`
left: `123`,
right: `456`: destination and source slices have different lengths', libcore/slice/mod.rs:1645:9
```
moxian [Tue, 8 May 2018 06:19:55 +0000 (06:19 +0000)]
Add a fallback for stacktrace printing for older Windows versions.
PR #47252 switched stack inspection functions of dbghelp.dll
to their newer alternatives that also capture inlined context.
Unfortunately, said new alternatives are not present in older
dbghelp.dll versions.
In particular Windows 7 at the time of writing has dbghelp.dll
version 6.1.7601 from 2010, that lacks StackWalkEx and friends.
bors [Thu, 28 Jun 2018 13:23:07 +0000 (13:23 +0000)]
Auto merge of #51630 - joshlf:map-split-perf, r=dtolnay
Optimize RefCell refcount tracking
Address the performance concern raised in https://github.com/rust-lang/rust/pull/51466#issuecomment-398255276
cc @dtolnay @nnethercote @rust-lang/wg-compiler-performance
cc @RalfJung @jhjourdan for soundness concerns
Can somebody kick off a perf run on this? I'm not sure how that's done, but I understand it has to be started manually.
The idea of this change is to switch to representing mutable refcount as values below 0 to eliminate some branching that was required with the old algorithm.
bors [Thu, 28 Jun 2018 11:20:41 +0000 (11:20 +0000)]
Auto merge of #50997 - michaelwoerister:pre-analyze-filemaps, r=Mark-Simulacrum
Make FileMap::{lines, multibyte_chars, non_narrow_chars} non-mutable.
This PR removes most of the interior mutability from `FileMap`, which should be beneficial, especially in a multithreaded setting. This is achieved by initializing the state in question when the filemap is constructed instead of during lexing. Hopefully this doesn't degrade performance.
The method relied on the FileMap still being under construction in
order for it to do what the name promises. It's now independent of
the current state.