There are at least a couple (and plausibly even three) diagnostics that
could use the spans of visibility modifiers in order to be reliably
correct (rather than hacking and munging surrounding spans to try to
infer where the visibility keyword must have been).

We follow the naming convention established by the other `Spanned` HIR
nodes: the "outer" type alias gets the "prime" node-type name, the
"inner" enum gets the name suffixed with an underscore, and the variant
names are prefixed with the prime name and `pub use` exported from here
(from HIR).

Thanks to veteran reviewer Vadim Petrochenkov for suggesting this
uniform approach. (A previous draft, based on the reasoning that
`Visibility::Inherited` should not have a span, tried to hack in a named
`span` field on `Visibility::Restricted` and a positional field on
`Public` and `Crate`. This was ... not so uniform.)

Visibility spans were added to the AST in #47799 (d6bdf296) as a
`Spanned<_>`—which means that we need to choose a span even in the case
of inherited visibility (what you get when there's no `pub` &c. keyword
at all). That initial implementation's choice is pretty
counterintuitive, which could matter if we want to use it as a site to
suggest inserting a visibility modifier, &c.

(The phrase "Schelling span" in the comment is meant in analogy to the
game-theoretic concept of a "Schelling point", a value that is chosen
simply because it's what one can expect to agree upon with other agents
in the absence of explicit coördination.)

Update the miri submodule

r? @kennytm

Bootstrap from 1.28.0 beta

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.

optimize `places_conflict` to avoid complex vectors etc

Fixes #51820

Point to lifetime spans on lifetime errors

Do not allow LLVM to increase a TLS's alignment on macOS.

This addresses the various TLS segfault on macOS 10.10.

Fix #51794.
Fix #51758.
Fix #50867.
Fix #48866.
Fix #46355.
Fix #44056.

hygiene: Implement transparent marks and use them for call-site hygiene in proc-macros

Fixes https://github.com/rust-lang/rust/issues/50050

Lowering cleanups [1/N]

Implement PartialEq between &str and OsString

This fixes #49854.

It allows equality comparison between `OsString` values and `str` references, such as `os_string == "something"`.

`$crate` is not resolved at def-site of a macro, but rather at "transitive def-site"

Fix incorrect type mismatch label pointing at return type

CC #46302.

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.

Update LLVM to 1c817c7a0c828b8fc8e8e462afbe5db41c7052d1

https://github.com/rust-lang/llvm/pull/118
https://github.com/rust-lang/llvm/pull/119

[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 #45699
Closes #46627
Closes #51187
Closes #51189

r? @pnkfelix

… since `std` has no corresponding reexports.

Use `alloc::vec::Vec` and `alloc::string::String` instead.

This matches std::collections

Allows for example `os_string == "something"`

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);`

https://github.com/rust-lang/llvm/pull/118
https://github.com/rust-lang/llvm/pull/119

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.