Rollup merge of #80720 - steffahn:prettify_prelude_imports, r=camelid,jyn514

Make documentation of which items the prelude exports more readable.

I recently figured out that rustdoc allows link inside of inline code blocks as long as they’re delimited with `<code> </code>` instead of `` ` ` ``. I think this applies nicely in the listing of prelude exports [in the docs](https://doc.rust-lang.org/std/prelude/index.html). There, currently unformatted `::` and `{ , }` is used in order to mimick import syntax while attatching links to individual identifiers.

## Rendered Comparison
### Currently (light)

### After this PR (light)

### Currently (dark)

### After this PR (dark)

### Currently (ayu)

### After this PR (ayu)

_Edit:_ I just noticed, the “current” screenshots are from stable, so there are a few more differences in the pictures than the ones from just this PR.

Auto merge of #83652 - xu-cheng:ipv4-octal, r=sfackler

Disallow octal format in Ipv4 string

In its original specification, leading zero in Ipv4 string is interpreted
as octal literals. So a IP address 0127.0.0.1 actually means 87.0.0.1.

This confusion can lead to many security vulnerabilities. Therefore, in
[IETF RFC 6943], it suggests to disallow octal/hexadecimal format in Ipv4
string all together.

Existing implementation already disallows hexadecimal numbers. This commit
makes Parser reject octal numbers.

Fixes #83648.

[IETF RFC 6943]: https://tools.ietf.org/html/rfc6943#section-3.1.1

Auto merge of #83639 - osa1:issue83638, r=estebank

Replace tabs in err messages before rendering

This is done in other call sites, but was missing in one place.

Fixes #83638

Auto merge of #83170 - joshtriplett:spawn-cleanup, r=kennytm

Simplify Command::spawn (no semantic change)

This minimizes the size of an unsafe block, and allows outdenting some
complex code.

Auto merge of #83674 - Dylan-DPC:rollup-bcuc1hl, r=Dylan-DPC

Rollup of 7 pull requests

Successful merges:

 - #83568 (update comment at MaybeUninit::uninit_array)
 - #83571 (Constantify some slice methods)
 - #83579 (Improve pointer arithmetic docs)
 - #83645 (Wrap non-pre code blocks)
 - #83656 (Add a regression test for issue-82865)
 - #83662 (Update books)
 - #83667 (Suggest box/pin/arc ing receiver on method calls)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup merge of #83667 - estebank:cool-bears-hot-tip, r=lcnr

Suggest box/pin/arc ing receiver on method calls

_Extracted from https://fasterthanli.me/articles/pin-and-suffering_

Rollup merge of #83662 - ehuss:update-books, r=ehuss

Update books

## reference

4 commits in d10a0af8dca25d9d548ca6a369fd66ad06acb3c9..fd97729e2d82f8b08d68a31c9bfdf0c37a7fd542
2021-03-21 11:14:06 -0700 to 2021-03-28 14:29:19 -0700
- Editorial cleanup on expressions (part 1) (rust-lang-nursery/reference#967)
- Update type casts section (rust-lang-nursery/reference#961)
- Add missing "?" notion (rust-lang-nursery/reference#989)
- Fix typo (rust-lang-nursery/reference#988)

## book

8 commits in fc2f690fc16592abbead2360cfc0a42f5df78052..b54090a99ec7c4b46a5203a9c927fdbc311bb1f5
2021-03-05 14:03:22 -0500 to 2021-03-24 11:21:46 -0500
- correct the signature of the `deref` method (rust-lang/book#2658)
- Clarify the immutability of a reference (rust-lang/book#2646)
- Tweak wording around Windows representation of enter
- Ch. 02 note - Enter results in CRLF on Windows (rust-lang/book#2648)
- Added an example of slicing result (rust-lang/book#2649)
- Fix word wrapping, mention dictionary.txt is also in the ci dir
- README: note that spellcheck.sh is in ci directory (rust-lang/book#2652)
- Change someurl.com to example.org (rust-lang/book#2655)

## rust-by-example

12 commits in eead22c6c030fa4f3a167d1798658c341199e2ae..29d91f591c90dd18fdca6d23f1a9caf9c139d0d7
2021-03-04 16:26:43 -0300 to 2021-03-23 09:03:39 -0300
- Unwrap some drinks. (rust-lang/rust-by-example#1431)
- doc(testcase_linked_list): add a little extra note about pattern (rust-lang/rust-by-example#1408)
- Update function name in comment (rust-lang/rust-by-example#1413)
- Fixes minor typo in src/types/cast.md (rust-lang/rust-by-example#1414)
- Add destructuring example to generics new type (rust-lang/rust-by-example#1416)
- update struct.md (rust-lang/rust-by-example#1419)
- fix name from rectangle to Rectangle (rust-lang/rust-by-example#1420)
- Typo "incures" in code comment (rust-lang/rust-by-example#1422)
- Changed impl to use Self::Item (rust-lang/rust-by-example#1425)
- Fix code highlighting in some places (rust-lang/rust-by-example#1427)
- Update multi_bounds.md (rust-lang/rust-by-example#1428)
- Reformulated text for redability (rust-lang/rust-by-example#1429)

## rustc-dev-guide

3 commits in 67ebd4b55dba44edfc351621cef6e5e758169c55..0687daac28939c476df51778f5a1d1aff1a3fddf
2021-03-11 13:36:25 -0800 to 2021-03-28 13:33:56 -0400
- Add notes about nightly rustc version for the rustc-driver examples
- Update rustc-driver-*.rs examples (rust-lang/rustc-dev-guide#1095)
- Fix rust compiler meeting info (rust-lang/rustc-dev-guide#1087)

## embedded-book

1 commits in f61685755fad7d3b88b4645adfbf461d500563a2..d3f2ace94d51610cf3e3c265705bb8416d37f8e4
2021-03-08 01:06:44 +0000 to 2021-03-17 07:53:09 +0000
- Add binary attribute to .jpeg files, closes rust-embedded/book#287  (rust-embedded/book#288)

Rollup merge of #83656 - JohnTitor:resolve-test, r=petrochenkov

Add a regression test for issue-82865

Closes #82865
r? `@petrochenkov`

Rollup merge of #83645 - pickfire:patch-3, r=GuillaumeGomez

Wrap non-pre code blocks

Fix #83550 regression

```
$ cargo new --lib whitespace && cd whitespace && echo '//! `"   foo   "`' > src/lib.rs && cargo doc --open
```

Before


After


r? ``@GuillaumeGomez``
cc ``@mgeisler``

Rollup merge of #83579 - RalfJung:ptr-arithmetic, r=dtolnay

Improve pointer arithmetic docs

* Add slightly more detailed definition of "allocated object" to the module docs, and link it from everywhere.
* Clarify the "remains attached" wording a bit (at least I hope this is clearer).
* Remove the sentence about using integer arithmetic; this seems to confuse people even if it is technically correct.

As usual, the edit needs to be done in a dozen places to remain consistent, I hope I got them all.

Rollup merge of #83571 - a1phyr:feature_const_slice_first_last, r=dtolnay

Constantify some slice methods

Tracking issue: #83570

This PR constantifies the following functions under feature `const_slice_first_last`:
- `slice::first`
- `slice::split_first`
- `slice::last`
- `slice::split_last`

Blocking on `#![feature(const_mut_refs)]`:
- `slice::first_mut`
- `slice::split_first_mut`
- `slice::last_mut`
- `slice::split_last_mut`

Rollup merge of #83568 - RalfJung:uninit_array, r=dtolnay

update comment at MaybeUninit::uninit_array

https://github.com/rust-lang/rust/issues/49147 is closed; this now instead needs inline const expressions (#76001).

Auto merge of #83458 - saethlin:improve-vec-benches, r=dtolnay

Clean up Vec's benchmarks

The Vec benchmarks need a lot of love. I sort of noticed this in https://github.com/rust-lang/rust/pull/83357 but the overall situation is much less awesome than I thought at the time. The first commit just removes a lot of asserts and does a touch of other cleanup.

A number of these benchmarks are poorly-named. For example, `bench_map_fast` is not in fact fast, `bench_rev_1` and `bench_rev_2` are vague, `bench_in_place_zip_iter_mut` doesn't call `zip`, `bench_in_place*` don't do anything in-place... Should I fix these, or is there tooling that depend on the names not changing?

I've also noticed that `bench_rev_1` and `bench_rev_2` are remarkably fragile. It looks like poking other code in `Vec` can cause the codegen of this benchmark to switch to a version that has almost exactly half its current throughput and I have absolutely no idea why.

Here's the fast version:
```asm
  0.69 │110:   movdqu -0x20(%rbx,%rdx,4),%xmm0
  1.76 │       movdqu -0x10(%rbx,%rdx,4),%xmm1
  0.71 │       pshufd $0x1b,%xmm1,%xmm1
  0.60 │       pshufd $0x1b,%xmm0,%xmm0
  3.68 │       movdqu %xmm1,-0x30(%rcx)
 14.36 │       movdqu %xmm0,-0x20(%rcx)
 13.88 │       movdqu -0x40(%rbx,%rdx,4),%xmm0
  6.64 │       movdqu -0x30(%rbx,%rdx,4),%xmm1
  0.76 │       pshufd $0x1b,%xmm1,%xmm1
  0.77 │       pshufd $0x1b,%xmm0,%xmm0
  1.87 │       movdqu %xmm1,-0x10(%rcx)
 13.01 │       movdqu %xmm0,(%rcx)
 38.81 │       add    $0x40,%rcx
  0.92 │       add    $0xfffffffffffffff0,%rdx
  1.22 │     ↑ jne    110
```
And the slow one:
```asm
  0.42 │9a880:   movdqa     %xmm2,%xmm1
  4.03 │9a884:   movq       -0x8(%rbx,%rsi,4),%xmm4
  8.49 │9a88a:   pshufd     $0xe1,%xmm4,%xmm4
  2.58 │9a88f:   movq       -0x10(%rbx,%rsi,4),%xmm5
  7.02 │9a895:   pshufd     $0xe1,%xmm5,%xmm5
  4.79 │9a89a:   punpcklqdq %xmm5,%xmm4
  5.77 │9a89e:   movdqu     %xmm4,-0x18(%rdx)
 15.74 │9a8a3:   movq       -0x18(%rbx,%rsi,4),%xmm4
  3.91 │9a8a9:   pshufd     $0xe1,%xmm4,%xmm4
  5.04 │9a8ae:   movq       -0x20(%rbx,%rsi,4),%xmm5
  5.29 │9a8b4:   pshufd     $0xe1,%xmm5,%xmm5
  4.60 │9a8b9:   punpcklqdq %xmm5,%xmm4
  9.81 │9a8bd:   movdqu     %xmm4,-0x8(%rdx)
 11.05 │9a8c2:   paddq      %xmm3,%xmm0
  0.86 │9a8c6:   paddq      %xmm3,%xmm2
  5.89 │9a8ca:   add        $0x20,%rdx
  0.12 │9a8ce:   add        $0xfffffffffffffff8,%rsi
  1.16 │9a8d2:   add        $0x2,%rdi
  2.96 │9a8d6: → jne        9a880 <<alloc::vec::Vec<T,A> as core::iter::traits::collect::Extend<&T>>::extend+0xd0>
```

Auto merge of #83649 - bjorn3:dedup_providers, r=petrochenkov

Don't duplicate the extern providers once for each crate

This should give a small perf improvement for small crates by avoiding a memcpy of a pretty big struct for each loaded crate. In addition would be useful for replacing the sequential `CrateNum` everywhere with the hash based `StableCrateId` introduced in #81635, which would allow avoiding remapping of `CrateNum`'s when loading crate metadata. While this PR is not strictly needed for that, it is necessary to prevent a performance loss due to it.

I think this duplication was done in https://github.com/rust-lang/rust/pull/40008 (which introduced the query system) to make it possible to compile multiple crates in a single session in the future. I think this is unlikely to be implemented any time soon. In addition this PR can easily be reverted if necessary to implement this.

Auto merge of #83357 - saethlin:vec-reserve-inlining, r=dtolnay

Reduce the impact of Vec::reserve calls that do not cause any allocation

I think a lot of callers expect `Vec::reserve` to be nearly free when no resizing is required, but unfortunately that isn't the case. LLVM makes remarkably poor inlining choices (along the path from `Vec::reserve` to `RawVec::grow_amortized`), so depending on the surrounding context you either get a huge blob of `RawVec`'s resizing logic inlined into some seemingly-unrelated function, or not enough inlining happens and/or the actual check in `needs_to_grow` ends up behind a function call. My goal is to make the codegen for `Vec::reserve` match the mental that callers seem to have: It's reliably just a `sub cmp ja` if there is already sufficient capacity.

This patch has the following impact on the serde_json benchmarks: https://github.com/serde-rs/json-benchmark/tree/ca3efde8a5b75ff59271539b67452911860248c7 run with `cargo +stage1 run --release -- -n 1024`

Before:
```
                                DOM                  STRUCT
======= serde_json ======= parse|stringify ===== parse|stringify ====
data/canada.json         340 MB/s   490 MB/s   630 MB/s   370 MB/s
data/citm_catalog.json   460 MB/s   540 MB/s  1010 MB/s   550 MB/s
data/twitter.json        330 MB/s   840 MB/s   640 MB/s   630 MB/s

======= json-rust ======== parse|stringify ===== parse|stringify ====
data/canada.json         580 MB/s   990 MB/s
data/citm_catalog.json   720 MB/s   660 MB/s
data/twitter.json        570 MB/s   960 MB/s
```

After:
```
                                DOM                  STRUCT
======= serde_json ======= parse|stringify ===== parse|stringify ====
data/canada.json         330 MB/s   510 MB/s   610 MB/s   380 MB/s
data/citm_catalog.json   450 MB/s   640 MB/s   970 MB/s   830 MB/s
data/twitter.json        330 MB/s   880 MB/s   670 MB/s   960 MB/s

======= json-rust ======== parse|stringify ===== parse|stringify ====
data/canada.json         560 MB/s  1130 MB/s
data/citm_catalog.json   710 MB/s   880 MB/s
data/twitter.json        530 MB/s  1230 MB/s

```

That's approximately a one-third increase in throughput on two of the benchmarks, and no effect on one (The benchmark suite has sufficient jitter that I could pick a run where there are no regressions, so I'm not convinced they're meaningful here).

This also produces perf increases on the order of 3-5% in a few other microbenchmarks that I'm tracking. It might be useful to see if this has a cascading effect on inlining choices in some large codebases.

Compiling this simple program demonstrates the change in codegen that causes the perf impact:
```rust
fn main() {
    reserve(&mut Vec::new());
}

#[inline(never)]
fn reserve(v: &mut Vec<u8>) {
    v.reserve(1234);
}
```

Before:
```rust
00000000000069b0 <scratch::reserve>:
    69b0:       53                      push   %rbx
    69b1:       48 83 ec 30             sub    $0x30,%rsp
    69b5:       48 8b 47 08             mov    0x8(%rdi),%rax
    69b9:       48 8b 4f 10             mov    0x10(%rdi),%rcx
    69bd:       48 89 c2                mov    %rax,%rdx
    69c0:       48 29 ca                sub    %rcx,%rdx
    69c3:       48 81 fa d1 04 00 00    cmp    $0x4d1,%rdx
    69ca:       77 73                   ja     6a3f <scratch::reserve+0x8f>
    69cc:       48 81 c1 d2 04 00 00    add    $0x4d2,%rcx
    69d3:       72 75                   jb     6a4a <scratch::reserve+0x9a>
    69d5:       48 89 fb                mov    %rdi,%rbx
    69d8:       48 8d 14 00             lea    (%rax,%rax,1),%rdx
    69dc:       48 39 ca                cmp    %rcx,%rdx
    69df:       48 0f 47 ca             cmova  %rdx,%rcx
    69e3:       48 83 f9 08             cmp    $0x8,%rcx
    69e7:       be 08 00 00 00          mov    $0x8,%esi
    69ec:       48 0f 47 f1             cmova  %rcx,%rsi
    69f0:       48 85 c0                test   %rax,%rax
    69f3:       74 17                   je     6a0c <scratch::reserve+0x5c>
    69f5:       48 8b 0b                mov    (%rbx),%rcx
    69f8:       48 89 0c 24             mov    %rcx,(%rsp)
    69fc:       48 89 44 24 08          mov    %rax,0x8(%rsp)
    6a01:       48 c7 44 24 10 01 00    movq   $0x1,0x10(%rsp)
    6a08:       00 00
    6a0a:       eb 08                   jmp    6a14 <scratch::reserve+0x64>
    6a0c:       48 c7 04 24 00 00 00    movq   $0x0,(%rsp)
    6a13:       00
    6a14:       48 8d 7c 24 18          lea    0x18(%rsp),%rdi
    6a19:       48 89 e1                mov    %rsp,%rcx
    6a1c:       ba 01 00 00 00          mov    $0x1,%edx
    6a21:       e8 9a fe ff ff          call   68c0 <alloc::raw_vec::finish_grow>
    6a26:       48 8b 7c 24 20          mov    0x20(%rsp),%rdi
    6a2b:       48 8b 74 24 28          mov    0x28(%rsp),%rsi
    6a30:       48 83 7c 24 18 01       cmpq   $0x1,0x18(%rsp)
    6a36:       74 0d                   je     6a45 <scratch::reserve+0x95>
    6a38:       48 89 3b                mov    %rdi,(%rbx)
    6a3b:       48 89 73 08             mov    %rsi,0x8(%rbx)
    6a3f:       48 83 c4 30             add    $0x30,%rsp
    6a43:       5b                      pop    %rbx
    6a44:       c3                      ret
    6a45:       48 85 f6                test   %rsi,%rsi
    6a48:       75 08                   jne    6a52 <scratch::reserve+0xa2>
    6a4a:       ff 15 38 c4 03 00       call   *0x3c438(%rip)        # 42e88 <_GLOBAL_OFFSET_TABLE_+0x490>
    6a50:       0f 0b                   ud2
    6a52:       ff 15 f0 c4 03 00       call   *0x3c4f0(%rip)        # 42f48 <_GLOBAL_OFFSET_TABLE_+0x550>
    6a58:       0f 0b                   ud2
    6a5a:       66 0f 1f 44 00 00       nopw   0x0(%rax,%rax,1)
```

After:
```asm
0000000000006910 <scratch::reserve>:
    6910:       48 8b 47 08             mov    0x8(%rdi),%rax
    6914:       48 8b 77 10             mov    0x10(%rdi),%rsi
    6918:       48 29 f0                sub    %rsi,%rax
    691b:       48 3d d1 04 00 00       cmp    $0x4d1,%rax
    6921:       77 05                   ja     6928 <scratch::reserve+0x18>
    6923:       e9 e8 fe ff ff          jmp    6810 <alloc::raw_vec::RawVec<T,A>::reserve::do_reserve_and_handle>
    6928:       c3                      ret
    6929:       0f 1f 80 00 00 00 00    nopl   0x0(%rax)
```

Hide unnecessary reference to trait

When the problem for a method not being found in its receiver is due to
arbitrary self-types, we don't want to mention importing or implementing
the trait, instead we suggest wrapping.

Disallow octal format in Ipv4 string

In its original specification, leading zero in Ipv4 string is interpreted
as octal literals. So a IP address 0127.0.0.1 actually means 87.0.0.1.

This confusion can lead to many security vulnerabilities. Therefore, in
[IETF RFC 6943], it suggests to disallow octal/hexadecimal format in Ipv4
string all together.

Existing implementation already disallows hexadecimal numbers. This commit
makes Parser reject octal numbers.

Fixes #83648.

[IETF RFC 6943]: https://tools.ietf.org/html/rfc6943#section-3.1.1

Auto merge of #83664 - Dylan-DPC:rollup-wx6idpd, r=Dylan-DPC

Rollup of 7 pull requests

Successful merges:

 - #82331 (alloc: Added `as_slice` method to `BinaryHeap` collection)
 - #83130 (escape_ascii take 2)
 - #83374 (unix: Fix feature(unix_socket_ancillary_data) on macos and other BSDs)
 - #83543 (Lint on unknown intra-doc link disambiguators)
 - #83636 (Add a regression test for issue-82792)
 - #83643 (Remove a FIXME resolved by #73578)
 - #83644 (:arrow_up: rust-analyzer)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

Suggest box/pin/arc ing receiver on method calls

Add a regression test for issue-82865

Rollup merge of #83644 - lnicola:rust-analyzer-2021-03-29, r=jonas-schievink

:arrow_up: rust-analyzer

Rollup merge of #83643 - JohnTitor:is-freeze-no-longer-uses-span, r=RalfJung

Remove a FIXME resolved by #73578

r? ``@RalfJung``

Rollup merge of #83636 - JohnTitor:const-generics-defualts-regg-test, r=lcnr

Add a regression test for issue-82792

Closes #82792

r? ``@lcnr``

Rollup merge of #83543 - camelid:lint-unknown-disambiguator, r=jyn514

Lint on unknown intra-doc link disambiguators

Rollup merge of #83374 - reyk:fix/bsd-ancillary, r=joshtriplett

unix: Fix feature(unix_socket_ancillary_data) on macos and other BSDs

This adds support for CMSG handling on macOS and fixes it on OpenBSD and possibly other BSDs.

When traversing the CMSG list, the previous code had an exception for Android where the next element after the last pointer could point to the first pointer instead of NULL.  This is actually not specific to Android: the `libc::CMSG_NXTHDR` implementation for Linux and emscripten have a special case to return NULL when the length of the previous element is zero; most other implementations simply return the previous element plus a zero offset in this case.

This MR makes the check non-optional which fixes CMSG handling and a possible endless loop on such systems; tested with file descriptor passing on OpenBSD, Linux, and macOS.

This MR additionally adds `SocketAncillary::is_empty` because clippy is right that it should be added.

This belongs to the `feature(unix_socket_ancillary_data)` tracking issue:  https://github.com/rust-lang/rust/issues/76915

r? `@joshtriplett`

Rollup merge of #83130 - clarfonthey:escape, r=m-ou-se

escape_ascii take 2

The previous PR, #73111 was closed for inactivity; since I've had trouble in the past reopening closed PRs, I'm just making a new one.

I'm still running the tests locally but figured I'd open the PR in the meantime. Will fix whatever errors show up so we don't have to wait again for this.

r? ``@m-ou-se``

Rollup merge of #82331 - frol:feat/std-binary-heap-as-slice, r=Amanieu

alloc: Added `as_slice` method to `BinaryHeap` collection

I initially asked about whether it is useful addition on https://internals.rust-lang.org/t/should-i-add-as-slice-method-to-binaryheap/13816, and it seems there were no objections, so went ahead with this PR.

> There is [`BinaryHeap::into_vec`](https://doc.rust-lang.org/std/collections/struct.BinaryHeap.html#method.into_vec), but it consumes the value. I wonder if there is API design limitation that should be taken into account. Implementation-wise, the inner buffer is just a Vec, so it is trivial to expose as_slice from it.

Please, guide me through if I need to add tests or something else.

UPD: Tracking issue #83659

Auto merge of #82864 - jyn514:short-circuit, r=GuillaumeGomez

rustdoc: Don't enter an infer_ctxt in get_blanket_impls for impls that aren't blanket impls

Less broken version of https://github.com/rust-lang/rust/pull/82856.

get_blanket_impls is a *very* hot region of rustdoc, so even small changes like this should help. Unfortunately I don't have benchmarks for this until https://github.com/rust-lang/rustc-perf/pull/802 is merged.

Update books

Simplify Command::spawn (no semantic change)

This minimizes the size of an unsafe block, and allows outdenting some
complex code.

Updated the tracking issue #

Auto merge of #83185 - jyn514:remove-dead-code, r=oli-obk

Remove (lots of) dead code

Builds on
- [ ] https://github.com/rust-lang/rust/pull/83161
- [x] https://github.com/rust-lang/rust/pull/83230
- [x] https://github.com/rust-lang/rust/pull/83197.

Found with https://github.com/est31/warnalyzer.
See https://github.com/rust-lang/rust/pull/77739 for a similar change in the past.

Dubious changes:
- Maybe some of the dead code in rustc_data_structures should be kept, in case someone wants to use it in the future?

TODO:
- [ ] check if any of the comments on the deleted code should be kept.
- [x] update the compiler documentation; right now it fails to build
- [x] finish moving `cfg(test)` changes into https://github.com/rust-lang/rust/pull/83197

cc `@est31`

Revert changes to sync data structures

There isn't currently a good reviewer for these, and I don't want to
remove things that will just be added again. I plan to make a separate
PR for these changes so the rest of the cleanup can land.

Auto merge of #80839 - tblah:riscv64linux_links, r=Mark-Simulacrum

Riscv64linux Test fixes

Get tests passing again using the riscv64gc-unknown-linux-gnu docker image.

Test with
```
src/ci/docker/run.sh riscv64gc-linux
```

## linkcheck
Linkcheck tests that interdocument links in the documentation are correct. Some interdocument links go between rustc and tools (such as rustdoc and cargo). When cross compiling, rustc is built for the host while some tools are built for the target. This goes for the documentation too. Because of this, links in the rustc documentation reffering to cargo or rustdoc documentation look broken.

This issue is worked around by disabling linkcheck for cross compilation builds.

## run-make tests

#78911 seems to happen because `--target` was not passed to `rustc`, but the target linker was specified, causing the target linker to be called with options intended for the host.

Resolves #78911

In a separate issue, `issue-36710` was trying to run a binary built for the target on the host system. This will not work for any platform using `remote-test-server`/`client` (such as riscv64). I don't know of a way of skipping those platforms specifically, so I set this test to skip only on riscv64 for now.

Don't duplicate the extern providers once for each crate

Auto merge of #83609 - klensy:c-str, r=m-ou-se

ffi::c_str removed bound checks on as_bytes, to_bytes

This removes bound checks on CString::as_bytes() and CStr::to_bytes() and adds test.

Wrap non-pre code blocks

Fix #83550 regression

Change back prelude headline

:arrow_up: rust-analyzer

Remove a FIXME resolved by #73578

ffi::c_str smaller as_bytes

Auto merge of #83637 - bjorn3:sync_cg_clif-2021-03-29, r=bjorn3

Sync rustc_codegen_cranelift

The main highlight of this sync is support for cross-compiling to Windows using MinGW. Native compilation with MinGW would also work I think, but using the MSVC toolchain is not yet supported as PE TLS is not yet implemented. Another nice improvement is that crate metadata is now loaded using mmap instead of by reading files. This improves compilation time a bit.

r? `@ghost`

`@rustbot` label +A-codegen +A-cranelift +T-compiler

Replace tabs in err messages before rendering

This is done in other call sites, but was missing in one place.

Fixes #83638

Merge commit '0969bc6dde001e01e7e1f58c8ccd7750f8a49ae1' into sync_cg_clif-2021-03-29

Prefer 4 spaces

Add a regression test for issue-82792

Auto merge of #83565 - RalfJung:miri, r=oli-obk

update Miri, and also run test suite with mir-opt-level=4

In the Miri repo, we run the Miri test suite once with default flags and once with `-O -Zmir-opt-level=4`. This helps identify and document situations where MIR optimizations mask UB -- it is okay for that to happen, but it might be god to look into it when it does happen. Recently these tests failed fairly frequently as new MIR optimizations were added, and since we only run them on the Miri side, it is not even clear which rustc PR introduced the change. So I propose we also run these tests in the rustc repo, such that toolstate tracking will tell us the exact PR (or at least the rollup) that caused the change.

r? `@oli-obk`
Fixes https://github.com/rust-lang/rust/issues/83590

Rustup to rustc 1.53.0-nightly (4a20eb6a9 2021-03-28)

Inline `find_suffix` closure that's only used once

Add test for weird backticks placement

Point to disambiguator instead of whole link

And, now that we do that, we can remove the explanatory note since the
error span should make it clear what the disambiguator is.

Auto merge of #83605 - RalfJung:unaligned, r=petrochenkov

unaligned_references: align(N) fields in packed(N) structs are fine

This removes some false positives from the unaligned_references lint: in a `repr(packed(2))` struct, fields of alignment 2 (and less) are guaranteed to be properly aligned, so we do not have to consider them "disaligned".

Add escape_default method to u8 and [u8]

Auto merge of #83619 - petrochenkov:nx, r=nagisa

linker: Use data execution prevention options by default when linker supports them

Do it in a centralized way in `link.rs` instead of individual target specs.
r? `@nagisa`

linker: Use data execution prevention options by default when linker supports them

Auto merge of #83602 - JohnTitor:cloudabi-flag-is-unnecessary, r=Xanewok

Remove unnecessary `ignore-cloudabi` flag

...since we dropped the CloudABI support.

ffi::c_str added tests for empty strings

test: run-make: skip tests on unsupported platforms

The tests issue-36710 and incr-prev-body-beyond-eof were changed in a
previous commit so that the correct target was passed to rustc
(previously rustc was building for the host not for the specific
target).

Since that change it turns out that these platforms never worked (they
only appeared to work because rustc was actually building for the host
architecture).

The wasm architectures fall over trying to build the C++ file in
issue-36710. They look for clang (which isn't installed in the
test-various docker container). If clang is installed, they can't find
a wasm c++ standard library to link to.

nvtptx64-nvidia-cuda fails in rustc saying it can't find std. The rust
platforms support page says that std is supported on cuda so this is
surprising.

dist-i586-gnu-i586-i686-musl can't find the C++ compiler. There is only
a musl-gcc and no musl-g++ in /musl-i586/bin/. The Docker image probably
needs tweaking.

test: run-make: flag tests which won't work in no-std environments

ci: docker: x86_64: specify host explicitly

bootstrap: don't run linkcheck when crosscompiling

When we cross compile, some things (and their documentation) are built
for the host (e.g. rustc), while others (and their documentation) are built
for the target. This generated documentation will have broken links
between documentation for different platforms e.g. between rustc and
cargo.

ci: docker: riscv64gc: specify host explicitly

run-make: skip issue-36710 on riscv64 and armhf

The test assumes it can run target binaries on the host. This not true
for riscv64 CI (or for other platforms using remote-test-server).

run-make: Specify --target to rustc

Resolves #78911

The target's linker was used but rustc wasn't told to build for that
target (instead defaulting to the host). This led to the host instead of
the target getting tested and to the linker getting inappropriate
arguments.

Auto merge of #83582 - jyn514:might-not, r=joshtriplett

may not -> might not

may not -> might not

"may not" has two possible meanings:
1. A command: "You may not stay up past your bedtime."
2. A fact that's only sometimes true: "Some cities may not have bike lanes."

In some cases, the meaning is ambiguous: "Some cars may not have snow
tires." (do the cars *happen* to not have snow tires, or is it
physically impossible for them to have snow tires?)

This changes places where the standard library uses the "description of
fact" meaning to say "might not" instead.

This is just `std::vec` for now - if you think this is a good idea I can
convert the rest of the standard library.

adjust old test

Auto merge of #83577 - geeklint:slice_to_ascii_case_doc_links, r=m-ou-se

Adjust documentation links for slice::make_ascii_*case

The documentation for the functions `slice::to_ascii_lowercase` and `slice::to_ascii_uppercase` contain the suggestion

> To lowercase the value in-place, use `make_ascii_lowercase`

however the link to the suggested method takes you to the page for `u8`, rather than the method of that name on the same page.

unaligned_references: align(N) fields in packed(N) structs are fine

update Miri

Auto merge of #83593 - petrochenkov:nounwrap, r=nagisa

rustc_target: Avoid unwraps when adding linker flags

These `unwrap`s assume that some linker flags were already added by `*_base::opts()` methods, but that's doesn't necessarily remain the case when we are reducing the number of flags hardcoded in targets, as https://github.com/rust-lang/rust/pull/83587 shows.

r? `@nagisa`

Remove unnecessary `ignore-cloudabi` flag

Auto merge of #81728 - Qwaz:fix-80335, r=joshtriplett

Fixes API soundness issue in join()

Fixes #80335

Auto merge of #81354 - SkiFire13:binary-search-assume, r=nagisa

Instruct LLVM that binary_search returns a valid index

This allows removing bound checks when the return value of `binary_search` is used to index into the slice it was call on. I also added a codegen test for this, not sure if it's the right thing to do (I didn't find anything on the dev guide), but it felt so.

Address more review comments

- Add back various diagnostic methods on `Session`.

  It seems unfortunate to duplicate these in so many places, but in the
  meantime, making the API inconsistent between `Session` and `Diagnostic`
  also seems unfortunate.

- Add back TyCtxtAt methods

  These will hopefully be used in the near future.

- Add back `with_const`, it would need to be added soon after anyway.
- Add back `split()` and `get_mut()`, they're useful.

Fix compiler docs

Address review comments

- Add back `HirIdVec`, with a comment that it will soon be used.
- Add back `*_region` functions, with a comment they may soon be used.
- Remove `-Z borrowck_stats` completely. It didn't do anything.
- Remove `make_nop` completely.
- Add back `current_loc`, which is used by an out-of-tree tool.
- Fix style nits
- Remove `AtomicCell` with `cfg(parallel_compiler)` for consistency.

Remove (lots of) dead code

Found with https://github.com/est31/warnalyzer.

Dubious changes:
- Is anyone else using rustc_apfloat? I feel weird completely deleting
  x87 support.
- Maybe some of the dead code in rustc_data_structures, in case someone
  wants to use it in the future?
- Don't change rustc_serialize

  I plan to scrap most of the json module in the near future (see
  https://github.com/rust-lang/compiler-team/issues/418) and fixing the
  tests needed more work than I expected.

TODO: check if any of the comments on the deleted code should be kept.

Remove unused `DiagnosticBuilder::sub` function

`Diagnostic::sub` is only ever used directly; it doesn't need to be
included in the builder.

Auto merge of #83587 - petrochenkov:asneeded, r=nagisa

linker: Use `--as-needed` by default when linker supports it

Do it in a centralized way in `link.rs` instead of individual target specs.
Majority of relevant target specs were already passing it.

rustc_target: Avoid unwraps when adding linker flags

linker: Use `--as-needed` by default when linker supports it

Auto merge of #83103 - petrochenkov:unilex, r=Aaron1011

resolve: Partially unify early and late scope-relative identifier resolution

Reuse `early_resolve_ident_in_lexical_scope` instead of a chunk of code in `resolve_ident_in_lexical_scope` doing the same job.

`early_resolve_ident_in_lexical_scope`/`visit_scopes` had to be slightly extended to be able to 1) start from a specific module instead of the current parent scope and 2) report one deprecation lint.
`early_resolve_ident_in_lexical_scope` still doesn't support walking through "ribs", that part is left in `resolve_ident_in_lexical_scope` (moreover, I'm pretty sure it's buggy, but that's a separate issue, cc https://github.com/rust-lang/rust/issues/52389 at least).

resolve: Partially unify early and late scope-relative ident resolution

may not -> might not

"may not" has two possible meanings:
1. A command: "You may not stay up past your bedtime."
2. A fact that's only sometimes true: "Some cities may not have bike lanes."

In some cases, the meaning is ambiguous: "Some cars may not have snow
tires." (do the cars *happen* to not have snow tires, or is it
physically impossible for them to have snow tires?)

This changes places where the standard library uses the "description of
fact" meaning to say "might not" instead.

This is just `std::vec` for now - if you think this is a good idea I can
convert the rest of the standard library.

Auto merge of #83580 - Dylan-DPC:rollup-1zod4p7, r=Dylan-DPC

Rollup of 8 pull requests

Successful merges:

 - #81351 (combine: stop eagerly evaluating consts)
 - #82525 (make unaligned_references future-incompat lint warn-by-default)
 - #82626 (update array missing `IntoIterator` msg)
 - #82917 (Add function core::iter::zip)
 - #82993 (rustdoc: Use diagnostics for error when including sources)
 - #83522 (Improve fs error open_from unix)
 - #83548 (Always preserve `None`-delimited groups in a captured `TokenStream`)
 - #83555 (Add #[inline] to io::Error methods)

Failed merges:

 - #83130 (escape_ascii take 2)

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup merge of #83555 - m-ou-se:inline-io-error-new-const, r=jackh726

Add #[inline] to io::Error methods

Fixes #82812

Rollup merge of #83548 - Aaron1011:capture-none-delims, r=petrochenkov

Always preserve `None`-delimited groups in a captured `TokenStream`

Previously, we would silently remove any `None`-delimiters when
capturing a `TokenStream`, 'flattenting' them to their inner tokens.
This was not normally visible, since we usually have
`TokenKind::Interpolated` (which gets converted to a `None`-delimited
group during macro invocation) instead of an actual `None`-delimited
group.

However, there are a couple of cases where this becomes visible to
proc-macros:
1. A cross-crate `macro_rules!` macro has a `None`-delimited group
   stored in its body (as a result of being produced by another
   `macro_rules!` macro). The cross-crate `macro_rules!` invocation
   can then expand to an attribute macro invocation, which needs
   to be able to see the `None`-delimited group.
2. A proc-macro can invoke an attribute proc-macro with its re-collected
   input. If there are any nonterminals present in the input, they will
   get re-collected to `None`-delimited groups, which will then get
   captured as part of the attribute macro invocation.

Both of these cases are incredibly obscure, so there hopefully won't be
any breakage. This change will allow more agressive 'flattenting' of
nonterminals in #82608 without losing `None`-delimited groups.

Rollup merge of #83522 - pickfire:patch-6, r=JohnTitor

Improve fs error open_from unix

Consistency for #79399
Suggested by JohnTitor

r? `@JohnTitor`

Not user if the error is too long now, do we handle long errors well?

Rollup merge of #82993 - camelid:source-use-diag, r=jyn514

rustdoc: Use diagnostics for error when including sources

This error probably almost never happens, but we should still use the
diagnostic infrastructure. My guess is that the error was added back
before rustdoc used the rustc diagnostic infrastructure (it was all
`println!` and `eprintln!` back then!) and since it likely rarely occurs
and this code doesn't change that much, no one thought to transition it
to using diagnostics.

Note that the old error was actually a warning (it didn't stop the rest
of doc building). It seems very unlikely that this would fail without
the rest of the doc build failing, so it makes more sense for it to be a
hard error.

The error looks like this:

    error: failed to render source code for `src/test/rustdoc/smart-punct.rs`: "bar": foo
      --> src/test/rustdoc/smart-punct.rs:3:1
       |
    3  | / #![crate_name = "foo"]
    4  | |
    5  | | //! This is the "start" of the 'document'! How'd you know that "it's" ...
    6  | | //!
    ...  |
    22 | | //! I say "don't smart-punct me -- please!"
    23 | | //! ```
       | |_______^

I wasn't sure how to trigger the error, so to create that message I
temporarily made rustdoc always emit it. That's also why it says "bar"
and "foo" instead of a real error message.

Note that the span of the diagnostic starts at line 3 because line 1 of
that file is a (non-doc) comment and line 2 is a blank line.

Rollup merge of #82917 - cuviper:iter-zip, r=m-ou-se

Add function core::iter::zip

This makes it a little easier to `zip` iterators:

```rust
for (x, y) in zip(xs, ys) {}
// vs.
for (x, y) in xs.into_iter().zip(ys) {}
```

You can `zip(&mut xs, &ys)` for the conventional `iter_mut()` and
`iter()`, respectively. This can also support arbitrary nesting, where
it's easier to see the item layout than with arbitrary `zip` chains:

```rust
for ((x, y), z) in zip(zip(xs, ys), zs) {}
for (x, (y, z)) in zip(xs, zip(ys, zs)) {}
// vs.
for ((x, y), z) in xs.into_iter().zip(ys).zip(xz) {}
for (x, (y, z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {}
```

It may also format more nicely, especially when the first iterator is a
longer chain of methods -- for example:

```rust
    iter::zip(
        trait_ref.substs.types().skip(1),
        impl_trait_ref.substs.types().skip(1),
    )
    // vs.
    trait_ref
        .substs
        .types()
        .skip(1)
        .zip(impl_trait_ref.substs.types().skip(1))
```

This replaces the tuple-pair `IntoIterator` in #78204.
There is prior art for the utility of this in [`itertools::zip`].

[`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html

Rollup merge of #82626 - lcnr:encode_with_shorthandb, r=estebank

update array missing `IntoIterator` msg

fixes #82602

r? ```@estebank``` do you know whether we can use the expr span in `rustc_on_unimplemented`? The label isn't too great rn

Rollup merge of #82525 - RalfJung:unaligned-ref-warn, r=petrochenkov

make unaligned_references future-incompat lint warn-by-default

and also remove the safe_packed_borrows lint that it replaces.

`std::ptr::addr_of!` has hit beta now and will hit stable in a month, so I propose we start fixing https://github.com/rust-lang/rust/issues/27060 for real: creating a reference to a field of a packed struct needs to eventually become a hard error; this PR makes it a warn-by-default future-incompat lint. (The lint already existed, this just raises its default level.) At the same time I removed the corresponding code from unsafety checking; really there's no reason an `unsafe` block should make any difference here.

For references to packed fields outside `unsafe` blocks, this means `unaligned_refereces` replaces the previous `safe_packed_borrows` warning with a link to https://github.com/rust-lang/rust/issues/82523 (and no more talk about unsafe blocks making any difference). So behavior barely changes, the warning is just worded differently. For references to packed fields inside `unsafe` blocks, this PR shows a new future-incompat warning.

Closes https://github.com/rust-lang/rust/issues/46043 because that lint no longer exists.

Rollup merge of #81351 - lcnr:big-money-big-prices, r=oli-obk

combine: stop eagerly evaluating consts

`super_relate_consts` eagerly evaluates constants which doesn't seem too great.

I now also finally understand why all of the unused substs test passed. The reason being
that we just evaluated the constants in `super_relate_consts` :laughing:

While this change isn't strictly necessary as evaluating consts here doesn't hurt, it still feels a lot cleaner to do it this way

r? `@oli-obk` `@nikomatsakis`

revert rustdoc links in core to use #method. because they link to alloc, which may not be available

clarify 'remains attached', and remove recommendation to use integer arithmetic

add definition of 'allocated object', and link it from relevant method docs

adjust documentation links for slice ascii case functions to use newer rustdoc link format

update links to make_ascii_lowercase for slice to point to methods on the same type, rather than on u8

Add the tracking issue for `#![feature(iter_zip)]`

Auto merge of #83573 - JohnTitor:rollup-28jnzsr, r=JohnTitor

Rollup of 10 pull requests

Successful merges:

 - #79399 (Use detailed and shorter fs error explaination)
 - #83348 (format macro argument parsing fix)
 - #83462 (ExitStatus: print "exit status: {}" rather than "exit code: {}" on unix)
 - #83526 (lazily calls some fns)
 - #83558 (Use DebugStruct::finish_non_exhaustive() in std.)
 - #83559 (Fix Debug implementation for RwLock{Read,Write}Guard.)
 - #83560 (Derive Debug for io::Chain instead of manually implementing it.)
 - #83561 (Improve Debug implementations of Mutex and RwLock.)
 - #83567 (Update rustup cross-compilation docs link)
 - #83569 (Add regression tests for #56445)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup