Co-authored-by: NYuki Okushi <jtitor@2k36.org>

Adapted from a suggestion by @m-ou-se.
Co-authored-by: NMara Bos <m-ou.se@m-ou.se>
Signed-off-by: NIan Jackson <ijackson@chiark.greenend.org.uk>

And withdraw the allegation of "abuse".

Adapted from a suggestion by @m-ou-se.
Co-authored-by: NMara Bos <m-ou.se@m-ou.se>
Signed-off-by: NIan Jackson <ijackson@chiark.greenend.org.uk>

There is discussion of this in #40230 which requests clarification.
Signed-off-by: NIan Jackson <ijackson@chiark.greenend.org.uk>

As per discussion here
 https://github.com/rust-lang/rust/pull/85377#pullrequestreview-660460501Signed-off-by: NIan Jackson <ijackson@chiark.greenend.org.uk>

In the docs for intrinsics::abort():

 * Strengthen the recommendation by to use process::abort instead.
 * Document the fact that it (ab)uses an LLVM debug trap and what the
   likely consequences are.
 * State that the precise behaviour is unstable.

In the docs for process::abort():

 * Promise that we have the same behaviour as C `abort()`.
 * Document the likely consequences, including, specifically, the
   consequences on Unix.

In the internal comment for unix::abort_internal:

 * Refer to the public docs for the public API functions.
 * Correct and expand the description of libc::abort.  Specifically:
 * Do not claim that abort() unregisters signal handlers.  It doesn't;
   it honours the SIGABRT handler.
 * Discuss, extensively, the issue with abort() flushing stdio buffers.
 * Describe the glibc behaviour in some detail.
Co-authored-by: NMark Wooding <mdw@distorted.org.uk>
Signed-off-by: NIan Jackson <ijackson@chiark.greenend.org.uk>

Use rustdoc.css for error index

Closes #86512.

Pretty-print macro matchers instead of using source code

Fixes #86208.

Convert `debug_assert!` to `assert!` in `Binder::dummy`

This is needed for #85350 not to be passed.
r? `@jackh726`

Rollup of 8 pull requests

Successful merges:

 - #86477 (E0716: clarify that equivalent code example is erroneous)
 - #86623 (Add check to ensure error code explanations are not removed anymore even if not emitted)
 - #86856 (Make x.py less verbose on failures)
 - #86858 (Stabilize `string_drain_as_str`)
 - #86859 (Add a regression test for issue-69323)
 - #86862 (re-export SwitchIntEdgeEffects)
 - #86864 (Add missing code example for Write::write_vectored)
 - #86874 (Bump deps)

Failed merges:

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

Bump deps

tidy: updated cargo_metadata to 0.12 (rustfmt only one left, that depends on 0.8 version in tree, waiting when it merges into rustc repo)

miow v0.3.6 -> v0.3.7, drops socket2 v0.3.19

curl v0.4.36 -> v0.4.38
curl-sys v0.4.42+curl-7.76.0 -> v0.4.44+curl-7.77.0
fixes CVE's https://curl.se/docs/vuln-7.76.0.html

Add missing code example for Write::write_vectored

re-export SwitchIntEdgeEffects

This makes it possible to use `switch_int_edge_effects` outside
`rustc_mir::dataflow::impls`.

Add a regression test for issue-69323

Closes #69323
r? `@jackh726`

Stabilize `string_drain_as_str`

Closes #76905, FCP is done: https://github.com/rust-lang/rust/issues/76905#issuecomment-873461688

Make x.py less verbose on failures

- Don't print the exact command run by rustbuild unless `--verbose` is set.
  This is almost always unhelpful, since it's just cargo with a lot of
  arguments (and you can't replicate it anyway unless you have the environment variables, which aren't printed by default).
- Don't print "Build completed unsuccessfully" unless --verbose is set.
  You can already tell the build failed by the errors above, and the
  time isn't particularly helpful.
- Don't print the full path to bootstrap. This is useless to everyone,
  even including when working on x.py itself. You can still opt-in to
  this being shown with `--verbose`, since it will throw an exception.

Before:

```
error[E0432]: unresolved import `x`
   --> library/std/src/lib.rs:343:5
    |
343 | use x;
    |     ^ no external crate `x`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0432`.
error: could not compile `std`

To learn more, run the command again with --verbose.
command did not execute successfully: "/home/joshua/rustc4/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "check" "--target" "x86_64-unknown-linux-gnu" "-Zbinary-dep-depinfo" "-j" "8" "--release" "--features" "panic-unwind backtrace" "--manifest-path" "/home/joshua/rustc4/library/test/Cargo.toml" "--message-format" "json-render-diagnostics"
expected success, got: exit status: 101
failed to run: /home/joshua/rustc4/build/bootstrap/debug/bootstrap check
Build completed unsuccessfully in 0:00:13
```

After:

```
error[E0432]: unresolved import `x`
   --> library/std/src/lib.rs:343:5
    |
343 | use x;
    |     ^ no external crate `x`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0432`.
error: could not compile `std`

To learn more, run the command again with --verbose.
```

cc https://github.com/rust-lang/rust/issues/86854, https://github.com/rust-lang/rust/pull/86022

r? `@Mark-Simulacrum`

Add check to ensure error code explanations are not removed anymore even if not emitted

The error explanations are useful in case you use older version of the compiler. Even more if they had an explanation. If they are not emitted, their explanations should be updated but not removed (as we did for a few of them, like E0001).

r? `@Mark-Simulacrum`

E0716: clarify that equivalent code example is erroneous

In E0716, there is a code block that is equivalent to the erroneous
code example. Especially when viewed with `rustc --explain`, it's
not obvious that it is also erroneous, and some users have been
confused when they try to change their code to match the erroneous
equivalent.

`@rustbot` label +A-diagnostics +D-newcomer-roadblock +T-compiler

Add examples to the various methods of `core::task::Poll`

This improves the documentation of the various methods of [`core::task::Poll`](https://doc.rust-lang.org/std/task/enum.Poll.html). These currently have fairly simple docs with no examples. This PR changes these methods to be closer to `core::option::Option` and adds usage examples (and importantly: tests!) to `Poll`'s methods.

cc/ `@rust-lang/wg-async-foundations`

## Screenshots

<details>
<summary>View generated rustdoc page</summary>
<image src="https://user-images.githubusercontent.com/2467194/123286616-59ee9b00-d50e-11eb-9e02-40269070f904.png" alt="Poll in core::task"></details>

curl v0.4.36 -> v0.4.38
curl-sys v0.4.42+curl-7.76.0 -> v0.4.44+curl-7.77.0
fixes cve's https://curl.se/docs/vuln-7.76.0.html

Hack: Ignore inference variables in certain queries

Fixes #84841
Fixes #86753

Some queries are not built to accept types with inference variables, which can lead to ICEs. These queries probably ought to be converted to canonical form, but as a quick workaround, we can return conservative results in the case that inference variables are found.

We should file a follow-up issue (and update the FIXMEs...) to do the proper refactoring.

cc `@arora-aman`

r? `@oli-obk`

Co-authored-by: NRémy Rakic <remy.rakic+github@gmail.com>

This is needed for #85350 not to be passed.

In E0716, there is a code block that is equivalent to the erroneous
code example. Especially when viewed with `rustc --explain`, it's
not obvious that it is also erroneous, and some users have been
confused when they try to change their code to match the erroneous
equivalent.

core: add unstable no_fp_fmt_parse to disable float formatting code

In some projects (e.g. kernel), floating point is forbidden. They can disable
hardware floating point support and use `+soft-float` to avoid fp instructions
from being generated, but as libcore contains the formatting code for `f32`
and `f64`, some fp intrinsics are depended. One could define stubs for these
intrinsics that just panic [1], but it means that if any formatting functions
are accidentally used, mistake can only be caught during the runtime rather
than during compile-time or link-time, and they consume a lot of space without
LTO.

This patch provides an unstable cfg `no_fp_fmt_parse` to disable these.
A panicking stub is still provided for the `Debug` implementation (unfortunately)
because there are some SIMD types that use `#[derive(Debug)]`.

[1]: https://lkml.org/lkml/2021/4/14/1028

Stabilize `str::from_utf8_unchecked` as `const`

This stabilizes `unsafe fn str::from_utf8_unchecked` as `const` pending FCP on #75196. By the time FCP finishes, the beta will have already been cut, so I've set 1.55 as the stable-since version.

(should also be +relnotes but I don't have the permission to do that)

r? `@m-ou-se`

Closes #75196

This makes it possible to use `switch_int_edge_effects` outside
`rustc_mir::dataflow::impls`.

Support allocation failures when interpreting MIR

This closes #79601 by handling the case where memory allocation fails during MIR interpretation, and translates that failure into an `InterpError`. The error message is "tried to allocate more memory than available to compiler" to make it clear that the memory shortage is happening at compile-time by the compiler itself, and that it is not a runtime issue.

Now that memory allocation can fail, it would be neat if Miri could simulate low-memory devices to make it easy to see how much memory a Rust program needs.

Note that this breaks Miri because it assumes that allocation can never fail.

Warn when `rustdoc::` group is omitted from lint names

When rustdoc lints were first made a tool lint, they gave an unconditional warning when you used the original name:
```
warning: lint `broken_intra_doc_links` has been renamed to `rustdoc::broken_intra_doc_links`
  --> $DIR/renamed-lint-still-applies.rs:2:9
   |
LL | #![deny(broken_intra_doc_links)]
   |         ^^^^^^^^^^^^^^^^^^^^^^ help: use the new name: `rustdoc::broken_intra_doc_links`
   |
   = note: `#[warn(renamed_and_removed_lints)]` on by default
```
That was reverted in https://github.com/rust-lang/rust/pull/83203 because adding `rustdoc::x` lints would cause the code to break on old versions of the compiler (due to https://github.com/rust-lang/rust/issues/66079#issuecomment-788589193, "fixed" in https://github.com/rust-lang/rust/pull/83216 in the sense that you can now opt-in to not breaking on nightly, which is not ideal but `register_tool` is a long way from stabilizing). Since https://github.com/rust-lang/rust/pull/80527 is now on 1.52.0 stable, we can re-enable the warning. For nightly users, they can change immediately and still have their code work on stable; for stable users, they can change their code in 12 weeks and still have it work up to 3 releases back (about 18 weeks). That seems reasonable to me.

r? `@Manishearth` cc `@rust-lang/rustdoc`