Rollup of 5 pull requests

Successful merges:

 - #53941 (rustdoc: Sort implementors)
 - #54181 (Suggest && and || instead of 'and' and 'or')
 - #54209 (Partially revert 674a5db1 "Fix undesirable fallout [from macro modularization]")
 - #54213 (De-overlap the lifetimes of `flow_inits` and `flow_{un,ever_}inits`.)
 - #54244 (Add a small search box to seach Rust's standary library)

Failed merges:

r? @ghost

Add a small search box to seach Rust's standary library

This change partially addresses #14572. No CSS doesn't look fancy
but at least it is functional.

De-overlap the lifetimes of `flow_inits` and `flow_{un,ever_}inits`.

This reduces `max-rss` for an `nll-check` build by 27% for `keccak`, and
by 8% for `inflate`.

r? @nikomatsakis

Partially revert 674a5db1 "Fix undesirable fallout [from macro modularization]"

Partially revert https://github.com/rust-lang/rust/commit/674a5db1a50e25dd60a8ee6669edee9a366c9fab

~~Closes~~ (see pnkfelix comments below) https://github.com/rust-lang/rust/issues/53675

Suggest && and || instead of 'and' and 'or'

Resolves #54109.

Note: competing pull reqeust: #54179

r? @csmoe

rustdoc: Sort implementors

Fixes #53812

use structured suggestion for "missing mut" label

Fixes #54133 for both NLL and non-NLL.

r? @estebank

I'm not super happy with the existing wording here, since it's now a suggestion. I wonder if the message would work better as something like "help: make binding mutable: `mut foo`"?

Also, are the `HELP` and `SUGGESTION` comments necessary?

stabilize slice_align_to

This is very hard to implement correctly, and leads to [serious bugs](https://github.com/llogiq/bytecount/pull/42) when done incorrectly. Moreover, this is needed to be able to run code that opportunistically exploits alignment on miri. So code using `align_to`/`align_to_mut` gets the benefit of a well-tested implementation *and* of being able to run in miri to test for (some kinds of) UB.

This PR also clarifies the guarantee wrt. the middle part being as long as possible.  Should the docs say under which circumstances the middle part could be shorter? Currently, that can only happen when running in miri.

rustc_resolve: allow only core, std, meta and --extern in Rust 2018 paths.

As per https://github.com/rust-lang/rust/issues/53166#issuecomment-419265401:
* Rust 2018 imports can no longer refer to crates not in "extern prelude"
  * `::foo` won't load a crate named `foo` unless `foo` is in the "extern prelude"
  * `extern crate foo;`, however, remains unchanged (can load arbitrary crates)
* `--extern crate_name` is added (note the lack of `=path`) as an unstable option
  * adds `crate_name` to the "extern prelude" (see above)
  * crate is searched in sysroot & library paths, just like `extern crate crate_name`.
  * `Cargo` support will be added later
* `core`, `std` and ~~`proc_macro`~~ `meta` are *always* available in the extern prelude
  * warning for interaction with `no_std` / `no_core` will be added later
  * **EDIT**: `proc_macro` was replaced by `meta`, see https://github.com/rust-lang/rust/issues/53166#issuecomment-421137230
    * note that there is no crate named `meta` being added, so `use meta::...;` will fail, we're only whitelisting it so we can start producing `uniform_paths` compatibility errors

Fixes #54006 (as the example now requires `--extern alloc`, which is unstable).
Fixes #54253 (hit during fixing RLS).

r? @petrochenkov cc @aturon @alexcrichton @Centril @joshtriplett

This reverts commit 9f53c87b, reversing
changes made to cba0fdf4.

Add option to run all tests

This adds the "--include-ignored" flag to libtest, which allows running ignored and unignored tests in one go.

Closes #50363

Add inspection and setter methods to proc_macro::Diagnostic.

A few useful methods for `proc_macro::Diagnostic`.

r? @alexcrichton

Update Clippy

Clippy one commit behind #54226. This should work

r? @Manishearth

Remove bitslice.rs

As the comment in `bitslice.rs` says:

> FIXME: merge with `bitvec`

This change partially addresses #14572. No CSS doesn't look fancy
but at least it is functional.

The way it defines implementations is unrealistic though.

A few cleanups for hir

- prefer `if let` to `match` when only 1 branch matters
- `chain` iterable items that are looped over in sequence
- `sort_by_key` instead of `sort_by` when possible
- change cloning `map`s to `cloned()`
- use `unwrap_or_else` and `ok` when applicable
- a few other minor readability improvements
- whitespace fixes

resolve: Introduce two sub-namespaces in macro namespace

Two sub-namespaces are introduced in the macro namespace - one for bang macros and one for attribute-like macros (attributes, derives).

"Sub-namespace" means this is not a newly introduced full namespace, the single macro namespace is still in place.
I.e. you still can't define/import two macros with the same name in a single module, `use` imports still import only one name in macro namespace (from any sub-namespace) and not possibly two.

However, when we are searching for a name used in a `!` macro call context (`my_macro!()`) we skip attribute names in scope, and when we are searching for a name used in attribute context (`#[my_macro]`/`#[derive(my_macro)]`) we are skipping bang macro names in scope.
In other words, bang macros cannot shadow attribute macros and vice versa.

For a non-macro analogy, we could e.g. skip non-traits when searching for `MyTrait` in `impl MyTrait for Type { ... }`.
However we do not do it in non-macro namespaces because we don't have practical issues with e.g. non-traits shadowing traits with the same name, but with macros we do, especially after macro modularization.

For `#[test]` and `#[bench]` we have a hack in the compiler right now preventing their shadowing by `macro_rules! test` and similar things. This hack was introduced after making `#[test]`/`#[bench]` built-in macros instead of built-in attributes (https://github.com/rust-lang/rust/pull/53410), something that needed to be done from the start since they are "active" attributes transforming their inputs.
Now they are passed through normal name resolution and can be shadowed, but that's a breaking change, so we have  a special hack basically applying this PR for `#[test]` and `#[bench]` only.

Soon all potentially built-in attributes will be passed through normal name resolution (https://github.com/rust-lang/rust/pull/53913) and that uncovers even more cases where the strict "macro namespace is a single namespace" rule needs to be broken.
For example, with strict rules, built-in macro `cfg!(...)` would shadow built-in attribute `#[cfg]` (they are different things), standard library macro `thread_local!(...)` would shadow built-in attribute `#[thread_local]` - both of these cases are covered by special hacks in https://github.com/rust-lang/rust/pull/53913 as well.
Crater run uncovered more cases of attributes being shadowed by user-defined macros (`warn`, `doc`, `main`, even `deprecated`), we cannot add exceptions in the compiler for all of them.

Regressions with user-defined attributes like https://github.com/rust-lang/rust/issues/53583 and https://github.com/rust-lang/rust/issues/53898 also appeared after enabling macro modularization.

People are also usually confused (https://github.com/rust-lang/rust/issues/53205#issuecomment-411552763, https://github.com/rust-lang/rust/issues/53583#issuecomment-415447800) when they see conflicts between attributes and non-attribute macros for the first time.

So my proposed solution is to solve this issue by introducing two sub-namespaces and thus skipping resolutions of the wrong kind and preventing more error-causing cases of shadowing.

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

rustc_resolve: don't treat uniform_paths canaries as ambiguities unless they resolve to distinct Def's.

In particular, this allows this pattern that @cramertj mentioned in https://github.com/rust-lang/rust/issues/53130#issuecomment-420848814:
```rust
use log::{debug, log};
fn main() {
    use log::{debug, log};
    debug!(...);
}
```
The canaries for the inner `use log::...;`, *in the macro namespace*, see the `log` macro imported at the module scope, and the (same) `log` macro, imported in the block scope inside `main`.

Previously, these two possible (macro namspace) `log` resolutions would be considered ambiguous (from a forwards-compat standpoint, where we might make imports aware of block scopes).

With this PR, such a case is allowed *if and only if* all the possible resolutions refer to the same definition (more specifically, because the *same* `log` macro is being imported twice).
This condition subsumes previous (weaker) checks like #54005 and the second commit of #54011.

Only the last commit is the main change, the other two are cleanups.

r? @petrochenkov cc @Centril @joshtriplett

[NLL] Suggest let binding

Closes #49821

Also adds an alternative to `explain_why_borrow_contains_point` that allows changing error messages based on the reason that will be given. This will also be useful for #51026, #51169 and maybe further changes to does not live long enough messages.

Addressed #53692

@sunjay @estebank  @csmoe hopefully this answer #53692
Please let me know if you have any suggestion

Add forever unstable attribute to allow specifying arbitrary scalar ranges

r? @EddyB for the first commit and @nikomatsakis for the second one

Rollup of 8 pull requests

Successful merges:

 - #53218 (Add a implementation of `From` for converting `&'a Option<T>` into `Option<&'a T>`)
 - #54024 (Fix compiling some rustc crates to wasm)
 - #54095 (Rename all mentions of `nil` to `unit`)
 - #54173 (Suggest valid crate type if invalid crate type is found)
 - #54194 (Remove println!() statement from HashMap unit test)
 - #54203 (Fix the stable release of os_str_str_ref_eq)
 - #54207 (re-mark the never docs as unstable)
 - #54210 (Update Cargo)

Failed merges:

r? @ghost

Update Cargo

Should bring in some nice progress bars for compilations!

re-mark the never docs as unstable

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

This stability attribute was removed in https://github.com/rust-lang/rust/pull/47630, but not replaced with a `#[stable]` attribute, and when https://github.com/rust-lang/rust/pull/50121 reverted that stabilization, it didn't set the docs back to unstable. I'm concerned as to why it was allowed to not have the stability attribute at all, but at least this can put it back.

I'm nominating this for beta backport because it's a really small change, and right now our docs are in an awkward position where the `!` type is technically unstable to use, but the docs don't say so the same way any other library feature would. (And this is also the case *on stable* now, but i'm not suggesting a stable backport for a docs fix.)

Fix the stable release of os_str_str_ref_eq

This was added and stabilized in commit 02503029, but while that
claimed to be for 1.28.0, it didn't actually make it until 1.29.0.

Fixes #54195.

Remove println!() statement from HashMap unit test

Suggest valid crate type if invalid crate type is found

This adds a suggestion to the `invalid_crate_types` lint.

The suggestion is based on the Levenshtein distance to existing crate
types. If no suggestion is found it will show the lint without any
suggestions.

Closes #53958

Rename all mentions of `nil` to `unit`

Fixes #53719.

Renamed keywords nil to unit.

Fix compiling some rustc crates to wasm

I was dabbling recently seeing what it would take to compile `rustfmt` to the
`wasm32-unknown-unknown` target and it turns out not much effort is needed!
Currently `rustfmt` depends on a few rustc crates published to crates.io, so
this commit touches up those crates to compile for wasm themselves. Notably:

* The `rustc_data_structures` crate's `flock` implementation is stubbed out to
  unconditionally return errors on unsupported platforms.
* The `rustc_errors` crate is extended to not do any locking for all non-windows
  platforms.

In both of these cases if we port the compiler to new platforms the
functionality isn't critical but will be discovered over time as it comes up, so
this hopefully doesn't make it too too hard to compile to new platforms!