Most of the time, it's not a problem that the types of the arm bodies in
a desugared-from-`?` match are different (that is, specifically: in `x?`
where x is a `Result<A, B>`, the `Ok` arm body is an `A`, whereas the
`Err` arm diverges to return a `Result<A, B>`), because they're being
assigned to different places. But in tail position, the types do need to
match, and our error message was explicitly referring to "match arms",
which is confusing when there's no `match` in the sweetly sugared
source.
It is not without some misgivings that we pollute the clarity-of-purpose
of `note_error_origin` with the suggestion to wrap with `Ok` (the other
branches are pointing out the odd-arm-out in the HIR that is the origin
of the error; the new branch that issues the `Ok` suggestion is serving
a different purpose), but it's the natural place to do it given that
we're already matching on `ObligationCauseCode::MatchExpressionArm {
arm_span, source }` there.
Resolves#51632.
Implement PartialEq between &str and OsString
This fixes#49854.
It allows equality comparison between `OsString` values and `str` references, such as `os_string == "something"`.
to not shadow the system installed LLD when linking with LLD.
Before:
- `-C linker=lld -Z linker-flavor=ld.lld` uses rustc's LLD
- It's not possible to use a system installed LLD that's named `lld`
With this commit:
- `-C linker=rust-lld -Z linker-flavor=ld.lld` uses rustc's LLD
- `-C linker=lld -Z linker-flavor=ld.lld` uses the system installed LLD
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.
[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.
Closes#45699Closes#46627Closes#51187Closes#51189
r? @pnkfelix
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.
Fixes#50138
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);`
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.
The current situation is something of a mess.
- `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)`.
Explicitely disable WASM code generation for Emscripten
Emscripten changed the default behavior recently:
bd050e64bb/ChangeLog.markdown (v1381-05172018)
It now defaults to WebAssembly and requires an explicit flag to generate asm.js.
WASM=0 is also valid for older emcc and thus doesn't break it.
