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`

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

Rollup merge of #83569 - sjakobi:issue56445-regression-test, r=jackh726

Add regression tests for #56445

Closes #56445.

Rollup merge of #83567 - jonjensen:patch-1, r=GuillaumeGomez

Update rustup cross-compilation docs link

Rollup merge of #83561 - m-ou-se:lock-debug, r=jackh726

Improve Debug implementations of Mutex and RwLock.

This improves the Debug implementations of Mutex and RwLock.

They now show the poison flag and use debug_non_exhaustive. (See #67364.)

Rollup merge of #83560 - m-ou-se:io-chain-debug, r=sfackler

Derive Debug for io::Chain instead of manually implementing it.

This derives Debug for io::Chain instead of manually implementing it.

The manual implementation has the same bounds, so I don't think there's any reason for a manual implementation. The names used in the derive implementation are even nicer (`first`/`second`) than the manual implementation (`t`/`u`), and include the `done_first` field too.

Rollup merge of #83559 - m-ou-se:rwlock-guard-debug-fix, r=jackh726

Fix Debug implementation for RwLock{Read,Write}Guard.

This would attempt to print the Debug representation of the lock that the guard has locked, which will try to lock again, fail, and just print `"<locked>"` unhelpfully.

After this change, this just prints the contents of the mutex, like the other smart pointers (and MutexGuard) do.

MutexGuard had this problem too: https://github.com/rust-lang/rust/issues/57702

Rollup merge of #83558 - m-ou-se:use-finish-non-exhaustive, r=jackh726

Use DebugStruct::finish_non_exhaustive() in std.

See https://github.com/rust-lang/rust/issues/67364

Rollup merge of #83526 - klensy:lazy-too, r=petrochenkov

lazily calls some fns

Replaced some fn's with it's lazy variants.

Rollup merge of #83462 - ijackson:exitstatus-message-wording, r=joshtriplett

ExitStatus: print "exit status: {}" rather than "exit code: {}" on unix

Proper Unix terminology is "exit status" (vs "wait status").  "exit
code" is imprecise on Unix and therefore unclear.  (As far as I can
tell, "exit code" is correct terminology on Windows.)

This new wording is unfortunately inconsistent with the identifier
names in the Rust stdlib.

It is the identifier names that are wrong, as discussed at length in eg
  https://doc.rust-lang.org/nightly/std/process/struct.ExitStatus.html
  https://doc.rust-lang.org/nightly/std/os/unix/process/trait.ExitStatusExt.html

Unfortunately for API stability reasons it would be a lot of work, and
a lot of disruption, to change the names in the stdlib (eg to rename
`std::process::ExitStatus` to `std::process::ChildStatus` or
something), but we should fix the message output.  Many (probably
most) readers of these messages about exit statuses will be users and
system administrators, not programmers, who won't even know that Rust
has this wrong terminology.

So I think the right thing is to fix the documentation (as I have
already done) and, now, the terminology in the implementation.

This is a user-visible change to the behaviour of all Rust programs
which run Unix subprocesses.  Hopefully no-one is matching against the
exit status string, except perhaps in tests.

Rollup merge of #83348 - osa1:issue83344, r=jackh726

format macro argument parsing fix

When the character next to `{}` is "shifted" (when mapping a byte index
in the format string to span) we should avoid shifting the span end
index, so first map the index of `}` to span, then bump the span,
instead of first mapping the next byte index to a span (which causes
bumping the end span too much).

Regression test added.

Fixes #83344

---

r? ```@estebank```

Rollup merge of #79399 - pickfire:patch-3, r=JohnTitor

Use detailed and shorter fs error explaination

Includes suggestion from `@the8472` https://github.com/rust-lang/rust/issues/79390#issuecomment-733263336

make unaligned_refereces future-incompat lint warn-by-default, and remove the safe_packed_borrows lint that it replaces

update tests

combine: stop eagerly evaluating consts

Add regression tests for #56445

Closes #56445.

Update rustup cross-compilation docs link

Auto merge of #83245 - the8472:generalize-slice-fill, r=m-ou-se

Generalize and inline slice::fill specializations

This makes the memset specialization applicable to more types. And since the code now lives in a generic method it is also eligible for cross-crate inlining which  should fix #83235

Use detailed and shorter fs error explaination

Includes suggestion from the8472 https://github.com/rust-lang/rust/issues/79390#issuecomment-733263336

More detail error explanation in fs doc

Improve Debug implementations of Mutex and RwLock.

They now show the poison flag and use debug_non_exhaustive.

Derive Debug for io::Chain instead of manually implementing it.

The manual implementation has the same bounds, so I don't think there's
any reason for a manual implementation. The names used in the derive
implementation are even nicer (`first`/`second`) than the manual
implementation (`t`/`u`), and include the `done_first` field too.

Fix Debug implementation for RwLock{Read,Write}Guard.

This would attempt to print the Debug representation of the lock that
the guard has locked, which will try to lock again, fail, and just print
"<locked>" unhelpfully.

After this change, this just prints the contents of the mutex, like the
other smart pointers (and MutexGuard) do.

Use DebugStruct::finish_non_exhaustive() in std.

Auto merge of #78618 - workingjubilee:ieee754-fmt, r=m-ou-se

Add IEEE 754 compliant fmt/parse of -0, infinity, NaN

This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values, namely signed zero, the infinities, and NaN. It also adds IEEE 754 compliance tests that, while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests, are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks.

This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074, and closes #24623.

The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers, i.e. not the extended reals (where floats live), IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely, when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition, the vast majority of other programming languages not only output `-0` but output `-0.0` here.

While IEEE 754 offers a broad leeway in how to handle producing what it calls a "decimal character sequence", it is clear that the operations a language provides should be capable of round tripping, and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further, existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character, but it prints "+0" instead if given such (which was what led to the opening of #24623).

There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard, as well as other well-documented challenges on the arithmetic level, but I hope that this can be the beginning of motion towards solving those challenges.

format macro argument parsing fix

When the character next to `{}` is "shifted" (when mapping a byte index
in the format string to span) we should avoid shifting the span end
index, so first map the index of `}` to span, then bump the span,
instead of first mapping the next byte index to a span (which causes
bumping the end span too much).

Regression test added.

Fixes #83344

Auto merge of #83547 - JohnTitor:rollup-qh7j6hg, r=JohnTitor

Rollup of 9 pull requests

Successful merges:

 - #83239 (Remove/replace some outdated crates from the dependency tree)
 - #83328 (Fixes to inline assmebly tests)
 - #83343 (Simplify and fix byte skipping in format! string parser)
 - #83388 (Make # pretty print format easier to discover)
 - #83431 (Tell GitHub to highlight `config.toml.example` as TOML)
 - #83508 (Use the direct link to the platform support page)
 - #83511 (compiletest: handle llvm_version with suffix like "12.0.0libcxx")
 - #83524 (Document that the SocketAddr memory representation is not stable)
 - #83525 (fix doc comment for `ty::Dynamic`)

Failed merges:

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

lazily calls some fns

Rollup merge of #83525 - rust-lang:lcnr-doc-patch, r=jonas-schievink

fix doc comment for `ty::Dynamic`

Rollup merge of #83524 - faern:document-socketaddr-mem-layout, r=sfackler

Document that the SocketAddr memory representation is not stable

Intended to help out with #78802. Work has been put into finding and fixing code that assumes the memory layout of `SocketAddrV4` and `SocketAddrV6`. But it turns out there are cases where new code continues to make the same assumption ([example](https://github.com/spacejam/seaslug/commit/96927dc2b7b918860a79c4eb6336051e52c6137a#diff-917db3d8ca6f862ebf42726b23c72a12b35e584e497ebdb24e474348d7c6ffb6R610-R621)).

The memory layout of a type in `std` is never part of the public API. Unless explicitly stated I guess. But since that is invalidly relied upon by a considerable amount of code for these particular types, it might make sense to explicitly document this. This can be temporary. Once #78802 lands it does not make sense to rely on the layout any longer, and this documentation can also be removed.

Rollup merge of #83511 - 12101111:fix-llvm-version-suffix, r=Mark-Simulacrum

compiletest: handle llvm_version with suffix like "12.0.0libcxx"

The previous code only remove the suffix begin with `-`, but Gentoo Linux [define `LLVM_VERSION_SUFFIX="libcxx"`](https://github.com/gentoo/gentoo/blob/604d79f327176eecb05293d7154e24231229cb31/sys-devel/llvm/llvm-11.1.0.ebuild#L378) when llvm is linked to libc++ and lead to a panic:

```
thread 'main' panicked at 'Malformed version component: ParseIntError { kind: InvalidDigit }', src/tools/compiletest/src/header.rs:968:28
```

This new code will handle all suffix not beginning with digit or dot.

Rollup merge of #83508 - JohnTitor:platform-support-link, r=joshtriplett

Use the direct link to the platform support page

Rollup merge of #83431 - camelid:config-example-gitattributes, r=Mark-Simulacrum

Tell GitHub to highlight `config.toml.example` as TOML

This should be a nice small quality of life improvement when looking at
`config.toml.example` on GitHub or looking at diffs of it in PRs.

Rollup merge of #83388 - alamb:alamb/fmt-dcs, r=Mark-Simulacrum

Make # pretty print format easier to discover

# Rationale:

I use (cargo cult?) three formats in rust:  `{}`, debug `{:?}`, and pretty-print debug `{:#?}`. I discovered `{:#?}` in some blog post or guide when I started working in Rust. While `#` is documented I think it is hard to discover. So taking the good advice of ```@carols10cents```  I am trying to improve the docs with a PR

As a reminder "pretty print" means that where `{:?}` will print something like
```
foo: { b1: 1, b2: 2}
```

`{:#?}` will prints something like
```
foo {
  b1: 1
  b2: 3
}
```

# Changes
Add an example to `fmt` to try and make it easier to discover `#`

Rollup merge of #83343 - osa1:issue83340, r=jackh726

Simplify and fix byte skipping in format! string parser

Fixes '\\' handling in format strings.

Fixes #83340

Rollup merge of #83328 - tmiasko:asm-test, r=joshtriplett

Fixes to inline assmebly tests

* Join test thread to make assertion effective in sym.rs test case
* Use a single codegen unit to reduce non-determinism in srcloc.rs test #82886

Rollup merge of #83239 - JohnTitor:reduce-deps, r=Mark-Simulacrum

Remove/replace some outdated crates from the dependency tree

- Remove `cloudabi` by updating `parking_lot` to 0.11.1.
- Replace `packed_simd` with `packed_simd2` by updating `bytecount` to 0.6.2.

Auto merge of #83418 - ehuss:update-cargo, r=ehuss

Update cargo

12 commits in 90691f2bfe9a50291a98983b1ed2feab51d5ca55..1e8703890f285befb5e32627ad4e0a0454dde1fb
2021-03-16 21:36:55 +0000 to 2021-03-26 16:59:39 +0000
- tests: Tolerate "exit status" in error messages (rust-lang/cargo#9307)
- Default macOS targets to `unpacked` debuginfo (rust-lang/cargo#9298)
- Fix publication of packages with metadata and resolver (rust-lang/cargo#9300)
- Fix config includes not working. (rust-lang/cargo#9299)
- Emit note when `--future-incompat-report` had nothing to report (rust-lang/cargo#9263)
- RFC 3052: Stop including authors field in manifests made by cargo new (rust-lang/cargo#9282)
- Refactor feature handling, and improve error messages. (rust-lang/cargo#9290)
- Split out cargo-util package for cargo-test-support. (rust-lang/cargo#9292)
- Fix redundant_semicolons warning in resolver-tests. (rust-lang/cargo#9293)
- Use serde's error message option to avoid implementing `Deserialize`. (rust-lang/cargo#9237)
- Allow `cargo update` to operate with the --offline flag (rust-lang/cargo#9279)
- Fix typo in faq.md (rust-lang/cargo#9285)

Update cargo

fix doc comment for `ty::Dynamic

Document that the SocketAddr memory representation is not stable

Auto merge of #83488 - Aaron1011:ban-expr-inner-attrs, r=petrochenkov

Ban custom inner attributes in expressions and statements

Split out from https://github.com/rust-lang/rust/pull/82608

Custom inner attributes are unstable, so this won't break any stable users.
This allows us to speed up token collection, and avoid a redundant call to `collect_tokens_no_attrs` when parsing an `Expr` that has outer attributes.

r? `@petrochenkov`

Auto merge of #83404 - michaelwoerister:issue83045, r=eddyb

Fix #83045 by moving some crate loading verification code to a better place

r? `@eddyb`

Auto merge of #82980 - tmiasko:import-cold-multiplier, r=michaelwoerister

Import small cold functions

The Rust code is often written under an assumption that for generic
methods inline attribute is mostly unnecessary, since for optimized
builds using ThinLTO, a method will be code generated in at least one
CGU and available for import.

For example, deref implementations for Box, Vec, MutexGuard, and
MutexGuard are not currently marked as inline, neither is identity
implementation of From trait.

In PGO builds, when functions are determined to be cold, the default
multiplier of zero will stop the import, no matter how trivial the
implementation.

Increase slightly the default multiplier from 0 to 0.1.

r? `@ghost`

Handle llvm_version with suffix like "12.0.0libcxx"

Auto merge of #83079 - osa1:issue83046, r=m-ou-se

Update char::escape_debug_ext to handle different escapes in strings and chars

Fixes #83046

The program

    fn main() {
        println!("{:?}", '"');
        println!("{:?}", "'");
    }

would previously print

    '\"'
    "\'"

With this patch it now prints:

    '"'
    "'"

Fix #83045 by moving some crate loading verification code to a better place.

Update char::escape_debug_ext to handle different escapes in strings vs. chars

Fixes #83046

The program

    fn main() {
        println!("{:?}", '"');
        println!("{:?}", "'");
    }

would previously print

    '\"'
    "\'"

With this patch it now prints:

    '"'
    "'"

Auto merge of #83480 - flip1995:clippyup, r=Dylan-DPC

Update Clippy

Bi-weekly Clippy update.

r? `@Manishearth`

Use the direct link to the platform support page

Auto merge of #83503 - Dylan-DPC:rollup-mqvjfav, r=Dylan-DPC

Rollup of 8 pull requests

Successful merges:

 - #83055 ([rustdoc] Don't document stripped items in JSON renderer.)
 - #83437 (Refactor #82270 as lint instead of an error)
 - #83444 (Fix bootstrap tests on beta)
 - #83456 (Add docs for Vec::from functions)
 - #83463 (ExitStatusExt: Fix missing word in two docs messages)
 - #83470 (Fix patch note about #80653 not mentioning nested nor recursive)
 - #83485 (Mark asm tests as requiring LLVM 10.0.1)
 - #83486 (Don't ICE when using `#[global_alloc]` on a non-item statement)

Failed merges:

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

Rollup merge of #83486 - Aaron1011:fix/global-alloc-error, r=petrochenkov

Don't ICE when using `#[global_alloc]` on a non-item statement

Fixes #83469

We need to return an `Annotatable::Stmt` if we were passed an
`Annotatable::Stmt`

Rollup merge of #83485 - Amanieu:asm_llvm10, r=joshtriplett

Mark asm tests as requiring LLVM 10.0.1

Rollup merge of #83470 - danielhenrymantilla:patch-1, r=jyn514

Fix patch note about #80653 not mentioning nested nor recursive

Which thus missed the point of the change: `rustdoc` already bundled documentation for methods accessible through one layer of `Deref`, it has now been enhanced to keep recursing 🙂

r? ``@jyn514``

Rollup merge of #83463 - ijackson:exitstatusext-doc-grammar, r=kennytm

ExitStatusExt: Fix missing word in two docs messages

Looks like I missed the lack of these "and"s.

Rollup merge of #83456 - notriddle:vec-from-docs, r=JohnTitor

Add docs for Vec::from functions

Part of #51430

Rollup merge of #83444 - Mark-Simulacrum:bootstrap-beta, r=pietroalbini

Fix bootstrap tests on beta

Forward-porting a fix from the beta branch, which led to test failure on beta.

r? ``@pietroalbini``

Rollup merge of #83437 - Amanieu:asm_syntax, r=petrochenkov

Refactor #82270 as lint instead of an error

This PR fixes several issues with #82270 which generated an error when `.intel_syntax` or `.att_syntax` was used in inline assembly:
- It is now a warn-by-default lint instead of an error.
- The lint only triggers on x86. `.intel_syntax` and `.att_syntax` are only valid on x86.
- The lint no longer provides machine-applicable suggestions for two reasons:
- These changes should not be made automatically since changes to assembly code can be very subtle.
- The template string is not always just a string: it can contain macro invocation (`concat!`), raw strings, escape characters, etc.

cc ``@asquared31415``

Rollup merge of #83055 - aDotInTheVoid:selective-strip-item-doc, r=jyn514

[rustdoc] Don't document stripped items in JSON renderer.

Fixes #80664, see [my comment there](https://github.com/rust-lang/rust/issues/80664#issuecomment-797557948) for why

Note that we already do something similar in `convert_item`:

https://github.com/rust-lang/rust/blob/bb4cdf8ec034dca5c056ec9295f38062e5b7e871/src/librustdoc/json/conversions.rs#L28-L31

``@rustbot`` modify labels: +T-rustdoc +A-rustdoc-json

r? ``@jyn514``
cc ``@CraftSpider``

Auto merge of #83465 - michaelwoerister:safe-read_raw_bytes, r=cjgillot

Allow for reading raw bytes from rustc_serialize::Decoder without unsafe code

The current `read_raw_bytes` method requires using `MaybeUninit` and `unsafe`. I don't think this is necessary. Let's see if a safe interface has any performance drawbacks.

This is a followup to #83273 and will make it easier to rebase #82183.

r? `@cjgillot`

Auto merge of #82873 - GuillaumeGomez:rustdoc-const-ty, r=jyn514

Rework rustdoc const type

This PR is mostly about two things:
 1. Not storing some information in the `clean::Constant` type
 2. Using `TyCtxt` in the formatting (which we will need in any case as we move forward in any case).

Also: I'm very curious of the perf change in here.

Thanks a lot `@danielhenrymantilla` for your `Captures` idea! It allowed me to solve the lifetime issue completely. :)

r? `@jyn514`

Avoid double-collection for expression nonterminals

Ban custom inner attributes in expressions and statements

Mark inline asm tests as requiring LLVM 10.0.1

Don't ICE when using `#[global_alloc]` on a non-item statement

Fixes #83469

We need to return an `Annotatable::Stmt` if we were passed an
`Annotatable::Stmt`

Auto merge of #82743 - jackh726:resolve-refactor, r=nikomatsakis

Refactor rustc_resolve::late::lifetimes to resolve per-item

There are some changes to tests that I'd like some feedback on; so this is still WIP.

The reason behind this change will (hopefully) allow us to (as part of #76814) be able to essentially use the lifetime resolve code to resolve *all* late bound vars (including those of super traits). Currently, it only resolves those that are *syntactically* in scope. In #76814, I'm essentially finding that I would essentially have to redo the passing of bound vars through scopes (i.e. when instantiating a poly trait ref), and that's what this code does anyways. However, to be able to do this (ask super traits what bound vars are in scope), we have to be able to resolve items separately.

The first commit is actually partially orthogonal. Essentially removing one use of late bound debruijn indices.

Not exactly sure who would be best to review here.
Let r? `@nikomatsakis`

Update Cargo.lock

Merge commit '0e87918536b9833bbc6c683d1f9d51ee2bf03ef1' into clippyup

Bless nll test

Auto merge of #6971 - flip1995:rustup, r=flip1995

Rustup

r? `@ghost`

changelog: none

Bump Clippy Version -> 0.1.53

Bump nightly version -> 2021-03-25

Merge remote-tracking branch 'upstream/master' into rustup

Auto merge of #83424 - cjgillot:noparam, r=lcnr

GenericParam does not need to be a HIR owner.

The special case is not required.

Universal impl traits design to regular generic parameters, and their content is owned by the enclosing item.

Existential (and opaque) impl traits generate their own enclosing item, and are collected through it.

Fix patch note about #80653 not mentioning nested nor recursive

Which thus missed the point of the change: `rustdoc` already bundled documentation for methods accessible through one layer of `Deref`, it now has been enhanced to keep recursing 🙂

write-up what is happening

Refactor #82270 as lint instead of an error

Auto merge of #83387 - cuviper:min-llvm-10, r=nagisa

Update the minimum external LLVM to 10

r? `@nikic`

Allow for reading raw bytes from rustc_serialize::Decoder without unsafe code.

ExitStatusExt: Fix missing word in two docs messages

Looks like I missed the lack of these "and"s.

Acked-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Auto merge of #82565 - m-ou-se:ununstabilize-bits, r=kennytm

Revert reverting of stabilizing integer::BITS.

Now that `lexical-core` has an updated version that won't break with this stabilization, let's try to stabilize this again.

See https://github.com/rust-lang/rust/issues/81654#issuecomment-778564715

Tracking issue with FCP: https://github.com/rust-lang/rust/issues/76904

ExitStatus: print "exit status: {}" rather than "exit code: {}"

Proper Unix terminology is "exit status" (vs "wait status").  "exit
code" is imprecise on Unix and therefore unclear.  (As far as I can
tell, "exit code" is correct terminology on Windows.)

This new wording is unfortunately inconsistent with the identifier
names in the Rust stdlib.

It is the identifier names that are wrong, as discussed at length in eg
  https://doc.rust-lang.org/nightly/std/process/struct.ExitStatus.html
  https://doc.rust-lang.org/nightly/std/os/unix/process/trait.ExitStatusExt.html

Unfortunately for API stability reasons it would be a lot of work, and
a lot of disruption, to change the names in the stdlib (eg to rename
`std::process::ExitStatus` to `std::process::ChildStatus` or
something), but we should fix the message output.  Many (probably
most) readers of these messages about exit statuses will be users and
system administrators, not programmers, who won't even know that Rust
has this wrong terminology.

So I think the right thing is to fix the documentation (as I have
already done) and, now, the terminology in the implementation.

This is a user-visible change to the behaviour of all Rust programs
which run Unix subprocesses.  Hopefully no-one is matching against the
exit status string, except perhaps in tests.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Change wording

Auto merge of #83445 - erikdesjardins:rmunion, r=RalfJung

RemoveZsts: don't touch unions

This should fix a Miri ICE

r? `@RalfJung`

Auto merge of #83307 - richkadel:cov-unused-functions-1.1, r=tmandry

coverage bug fixes and optimization support

Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to
address multiple, somewhat related issues.

Fixed a significant flaw in prior coverage solution: Every counter
generated a new counter variable, but there should have only been one
counter variable per function. This appears to have bloated .profraw
files significantly. (For a small program, it increased the size by
about 40%. I have not tested large programs, but there is anecdotal
evidence that profraw files were way too large. This is a good fix,
regardless, but hopefully it also addresses related issues.

Fixes: #82144
Invalid LLVM coverage data produced when compiled with -C opt-level=1

Existing tests now work up to at least `opt-level=3`. This required a
detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR
when compiled with coverage, and a lot of trial and error with codegen
adjustments.

The biggest hurdle was figuring out how to continue to support coverage
results for unused functions and generics. Rust's coverage results have
three advantages over Clang's coverage results:

1. Rust's coverage map does not include any overlapping code regions,
   making coverage counting unambiguous.
2. Rust generates coverage results (showing zero counts) for all unused
   functions, including generics. (Clang does not generate coverage for
   uninstantiated template functions.)
3. Rust's unused functions produce minimal stubbed functions in LLVM IR,
   sufficient for including in the coverage results; while Clang must
   generate the complete LLVM IR for each unused function, even though
   it will never be called.

This PR removes the previous hack of attempting to inject coverage into
some other existing function instance, and generates dedicated instances
for each unused function. This change, and a few other adjustments
(similar to what is required for `-C link-dead-code`, but with lower
impact), makes it possible to support LLVM optimizations.

Fixes: #79651
Coverage report: "Unexecuted instantiation:..." for a generic function
from multiple crates

Fixed by removing the aforementioned hack. Some "Unexecuted
instantiation" notices are unavoidable, as explained in the
`used_crate.rs` test, but `-Zinstrument-coverage` has new options to
back off support for either unused generics, or all unused functions,
which avoids the notice, at the cost of less coverage of unused
functions.

Fixes: #82875
Invalid LLVM coverage data produced with crate brotli_decompressor

Fixed by disabling the LLVM function attribute that forces inlining, if
`-Z instrument-coverage` is enabled. This attribute is applied to
Rust functions with `#[inline(always)], and in some cases, the forced
inlining breaks coverage instrumentation and reports.

FYI: `@wesleywiser`

r? `@tmandry`

Auto merge of #6959 - ebobrow:iss-6927-fix, r=camsteffen

Check for `.to_string().into_bytes()` in string_lit_to_bytes

fixes #6927

changelog: Add a check for `into_bytes()` to string_lit_to_bytes lint

Auto merge of #83454 - JohnTitor:rollup-9ae0565, r=JohnTitor

Rollup of 8 pull requests

Successful merges:

 - #83041 (stabilize debug_non_exhaustive)
 - #83349 (Remove Option::{unwrap_none, expect_none}.)
 - #83420 (Add documentation for rustdoc-gui tests)
 - #83421 (Add Result::into_err where the Ok variant is the never type)
 - #83427 (small cleanups in rustc_errors / emitter)
 - #83434 (Update RELEASES.md)
 - #83440 (Use intra-doc link in core::cell)
 - #83442 (LLVMWrapper: attractive nuisance macros)

Failed merges:

 - #83438 (Update RELEASES.md)

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

Add docs for Vec::from functions

Part of #51430

check for `.to_string().into_bytes()` in string_lit_to_bytes

apply changes from review

Rollup merge of #83442 - durin42:remove-questionable-macros, r=cuviper

LLVMWrapper: attractive nuisance macros

This came up in the review of #83425: it's hard to imagine a use of
LLVM_VERSION_LE() or LLVM_VERSION_EQ() that's not asking for trouble
when a point release gets created, so let's just discard them to prevent
the issue.

Rollup merge of #83440 - fee1-dead:core-cell-intralink, r=jyn514

Use intra-doc link in core::cell

``@rustbot`` label T-doc A-intra-doc-links

r? ``@jyn514``

Rollup merge of #83434 - wesleywiser:update_releases, r=Mark-Simulacrum

Update RELEASES.md

This change was backed out in #83412 so we should remove the reference
to it from the release notes.

Rollup merge of #83427 - llogiq:refactor-emitter, r=estebank

small cleanups in rustc_errors / emitter

This is either moving code around so it gets called less often or using if let instead of match in a few cases.

Rollup merge of #83421 - faern:add-into-err, r=joshtriplett

Add Result::into_err where the Ok variant is the never type

Equivalent of #66045 but for the inverse situation where `T: Into<!>` rather than `E: Into<!>`.

I'm using the same feature gate name. I can't see why one of these methods would be OK to stabilize but not the other.

Tracking issue: #61695

Rollup merge of #83420 - GuillaumeGomez:rustdoc-gui-tests-doc, r=CraftSpider

Add documentation for rustdoc-gui tests

I think a bit of documentation doesn't hurt in this case considering how "out of the ordinary" this is.

r? ``@jyn514``

Rollup merge of #83349 - m-ou-se:unwrap-none, r=dtolnay

Remove Option::{unwrap_none, expect_none}.

This removes `Option::unwrap_none` and `Option::expect_none` since we're not going to stabilize them, see https://github.com/rust-lang/rust/issues/62633.

Closes #62633

Rollup merge of #83041 - guswynn:stable_debug_struct, r=m-ou-se

stabilize debug_non_exhaustive

tracking issue: https://github.com/rust-lang/rust/issues/67364

but it is still an open question whether the other `Debug*` struct's should have a similar method. I would guess that would best be put underneath a new feature gate, as this one seems uncontroversial enough to stabilize as is

Bump debug_non_exhaustive stabilization to 1.53.

Bump int_bits_const stable version to 1.53.

Revert "Revert stabilizing integer::BITS."