Necessary to handle WIFSTOPPED.
Signed-off-by: NIan Jackson <ijackson@chiark.greenend.org.uk>

This is essential for proper reporting of child process status on Unix.
Signed-off-by: NIan Jackson <ijackson@chiark.greenend.org.uk>

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

We need to be clear that this never returns WSTOPSIG.  That is, if
WIFSTOPPED, the return value is None.
Signed-off-by: NIan Jackson <ijackson@chiark.greenend.org.uk>

A unix wait status can contain, at least, exit statuses, termination
signals, and stop signals.

WTERMSIG is only valid if WIFSIGNALED.

https://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html

It will not be easy to experience this bug with `Command`, because
that doesn't pass WUNTRACED.  But you could make an ExitStatus
containing, say, a WIFSTOPPED, from a call to one of the libc wait
functions.

(In the WIFSTOPPED case, there is WSTOPSIG.  But a stop signal is
encoded differently to a termination signal, so WTERMSIG and WSTOPSIG
are by no means the same.)
Signed-off-by: NIan Jackson <ijackson@chiark.greenend.org.uk>

Stabilize split_inclusive

### Contents of this MR

This stabilises:

 * `slice::split_inclusive`
 * `slice::split_inclusive_mut`
 * `str::split_inclusive`

Closes #72360.

### A possible concern

The proliferation of `split_*` methods is not particularly pretty.  The existence of `split_inclusive` seems to invite the addition of `rsplit_inclusive`, `splitn_inclusive`, etc.  We could instead have a more general API, along these kinds of lines maybe:
```
   pub fn split_generic('a,P,H>(&'a self, pat: P, how: H) -> ...
       where P: Pattern
       where H: SplitHow;

   pub fn split_generic_mut('a,P,H>(&'a mut self, pat: P, how: H) -> ...
       where P: Pattern
       where H: SplitHow;

   trait SplitHow {
       fn reverse(&self) -> bool;
       fn inclusive -> bool;
       fn limit(&self) -> Option<usize>;
   }

   pub struct SplitFwd;
   ...
   pub struct SplitRevInclN(pub usize);
```
But maybe that is worse.

### Let us defer that? ###

This seems like a can of worms.  I think we can defer opening it now; if and when we have something more general, these two methods can become convenience aliases.  But I thought I would mention it so the lang API team can consider it and have an opinion.

Rollup of 10 pull requests

Successful merges:

 - #78901 (diagnostics: Note capturing closures can't be coerced to fns)
 - #79588 (Provide more information for HRTB lifetime errors involving closures)
 - #80232 (Remove redundant def_id lookups)
 - #80662 (Added support for i386-unknown-linux-gnu and i486-unknown-linux-gnu)
 - #80736 (use Once instead of Mutex to manage capture resolution)
 - #80796 (Update to LLVM 11.0.1)
 - #80859 (Fix --pretty=expanded with --remap-path-prefix)
 - #80922 (Revert "Auto merge of #76896 - spastorino:codegen-inline-fns2)
 - #80924 (Fix rustdoc --test-builder argument parsing)
 - #80935 (Rename `rustc_middle::lint::LevelSource` to `LevelAndSource`)

Failed merges:

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

Rename `rustc_middle::lint::LevelSource` to `LevelAndSource`

This continues work in https://github.com/rust-lang/rust/pull/80274 to improve code readability.

This naming follows a pattern seen elsewhere in the compiler (e.g. [`rustc_middle::ty::TypeAndMut`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TypeAndMut.html)).

Fix rustdoc --test-builder argument parsing

My suggested fix to issue #80893. I can actually hook Miri in there now.

I also fixed what I believe to be a typo in the option's help text.

Revert "Auto merge of #76896 - spastorino:codegen-inline-fns2

This reverts commit ddf2cc7f, reversing
changes made to 937f6295.

As `@alexcrichton` pointed out in https://github.com/rust-lang/rust/issues/80916 there's a problem with the taken approach.

Fix --pretty=expanded with --remap-path-prefix

Per https://github.com/rust-lang/rust/issues/80832, using
--pretty=expanded and --remap-path-prefix results in an ICE.

This is becasue the session source files table is stored in remapped
form, whereas --pretty-expanded looks up unremapped files. This remaps
the path prefixes before lookup.

~~There don't appear to be any existing tests for --pretty=expanded; I'll look into
adding some.~~ Never mind, found the pretty tests.

Fixes #80832

Update to LLVM 11.0.1

This updates to a new LLVM branch, rebased on the upstream `llvmorg-11.0.1`. All our patches applied cleanly except the fortanix unwind changes, which just needed a small adjustment in cmake files.

r? `@nikic`
Fixes https://github.com/rust-lang/rust/issues/73722

use Once instead of Mutex to manage capture resolution

For #78299

This allows us to return borrows of the captured backtrace frames that are tied to a borrow of the Backtrace itself, instead of to some short-lived Mutex guard.

We could alternatively share `&Mutex<Capture>`s and lock on-demand, but then we could potentially forget to call `resolve()` before working with the capture. It also makes it semantically clearer what synchronization is needed on the capture.

cc `@seanchen1991` `@rust-lang/project-error-handling`

Added support for i386-unknown-linux-gnu and i486-unknown-linux-gnu

Support for both can be useful when creating new firmware, boot loaders,
or embedded operating systems.

Remove redundant def_id lookups

Simplify `DefId -> LocalDefId -> HirId -> LocalDefId -> DefId` chains.

Provide more information for HRTB lifetime errors involving closures

diagnostics: Note capturing closures can't be coerced to fns

Fixes #72457, fixes #71895

r? `@estebank`

Separate out a `hir::Impl` struct

This makes it possible to pass the `Impl` directly to functions, instead
of having to pass each of the many fields one at a time. It also
simplifies matches in many cases.

See `rustc_save_analysis::dump_visitor::process_impl` or `rustdoc::clean::clean_impl` for a good example of how this makes `impl`s easier to work with.

r? `@petrochenkov` maybe?

This makes it possible to pass the `Impl` directly to functions, instead
of having to pass each of the many fields one at a time. It also
simplifies matches in many cases.

Turn type inhabitedness into a query to fix `exhaustive_patterns` perf

We measured in https://github.com/rust-lang/rust/pull/79394 that enabling the [`exhaustive_patterns` feature](https://github.com/rust-lang/rust/issues/51085) causes significant perf degradation. It was conjectured that the culprit is type inhabitedness checking, and [I hypothesized](https://github.com/rust-lang/rust/pull/79394#issuecomment-733861149) that turning this computation into a query would solve most of the problem.

This PR turns `tcx.is_ty_uninhabited_from` into a query, and I measured a 25% perf gain on the benchmark that stress-tests `exhaustiveness_patterns`. This more than compensates for the 30% perf hit I measured [when creating it](https://github.com/rust-lang/rustc-perf/pull/801). We'll have to measure enabling the feature again, but I suspect this fixes the perf regression entirely.
I'd like a perf run on this PR obviously.
I made small atomic commits to help reviewing. The first one is just me discovering the "revisions" feature of the testing framework.

I believe there's a push to move things out of `rustc_middle` because it's huge. I guess `inhabitedness/mod.rs` could be moved out, but it's quite small. `DefIdForest` might be movable somewhere too. I don't know what the policy is for that.

Ping `@camelid` since you were interested in following along
`@rustbot` modify labels: +A-exhaustiveness-checking

Since `DefIdForest` contains 0 or 1 elements the large majority of the
time, by allocating only in the >1 case we avoid almost all allocations,
compared to `Arc<SmallVec<[DefId;1]>>`. This shaves off 0.2% on the
benchmark that stresses uninhabitedness checking.

Use tcx.symbol_name when determining clashing extern declarations.

Fixes #79581.

r? `@alexcrichton`

Make CTFE able to check for UB...

... by not doing any optimizations on the `const fn` MIR used in CTFE. This means we duplicate all `const fn`'s MIR now, once for CTFE, once for runtime. This PR is for checking the perf effect, so we have some data when talking about https://github.com/rust-lang/const-eval/blob/master/rfcs/0000-const-ub.md

To do this, we now have two queries for obtaining mir: `optimized_mir` and `mir_for_ctfe`. It is now illegal to invoke `optimized_mir` to obtain the MIR of a const/static item's initializer, an array length, an inline const expression or an enum discriminant initializer. For `const fn`, both `optimized_mir` and `mir_for_ctfe` work, the former returning the MIR that LLVM should use if the function is called at runtime. Similarly it is illegal to invoke `mir_for_ctfe` on regular functions.

This is all checked via appropriate assertions and I don't think it is easy to get wrong, as there should be no `mir_for_ctfe` calls outside the const evaluator or metadata encoding. Almost all rustc devs should keep using `optimized_mir` (or `instance_mir` for that matter).

Co-authored-by: NJoshua Nelson <joshua@yottadb.com>

Enhance type inference errors involving the `?` operator

This patch adds a special-cased note on type inference errors when the error span points to a `?` return. It also makes the primary label for such errors "cannot infer type of `?` error" in cases where before we would have only said "cannot infer type".

One beneficiary of this change is async blocks, where we can't explicitly annotate the return type and so may not generate any other help (#77880); this lets us at least print the error type we're converting from and anything we know about the type we can't fully infer. More generally, it signposts that an implicit conversion is happening that may have impeded type inference the user was expecting. We already do something similar for [mismatched type errors](https://github.com/rust-lang/rust/blob/2987785df3d46d5ff144a5c67fbb8f5cca798d78/src/test/ui/try-block/try-block-bad-type.stderr#L7).

The check for a relevant `?` operator is built into the existing HIR traversal which looks for places that could be annotated to resolve the error. That means we could identify `?` uses anywhere in the function that output the type we can't infer, but this patch just sticks to adding the note if the primary span given for the error has the operator; if there are other expressions where the type occurs and one of them is selected for the error instead, it's more likely that the `?` operator's implicit conversion isn't the sole cause of the inference failure and that adding an additional diagnostic would just be noise. I added a ui test for one such case.

The data about the `?` conversion is passed around in a `UseDiagnostic` enum that in theory could be used to add more of this kind of note in the future. It was also just easier to pass around than something with a more specific name. There are some follow-up refactoring commits for the code that generates the error label, which was already pretty involved and made a bit more complicated by this change.

remove redundant closures (clippy::redundant_closure)

Rollup of 8 pull requests

Successful merges:

 - #79757 (Replace tabs earlier in diagnostics)
 - #80600 (Add `MaybeUninit` method `array_assume_init`)
 - #80880 (Move some tests to more reasonable directories)
 - #80897 (driver: Use `atty` instead of rolling our own)
 - #80898 (Add another test case for #79808)
 - #80917 (core/slice: remove doc comment about scoped borrow)
 - #80927 (Replace a simple `if let` with the `matches` macro)
 - #80930 (fix typo in trait method mutability mismatch help)

Failed merges:

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

fix typo in trait method mutability mismatch help

Replace a simple `if let` with the `matches` macro

`@rustbot` modify labels +C-cleanup +T-compiler