Ideally, we should make use of CloudABI's internal proc_raise(SIGABRT)
system call. POSIX abort() requires things like flushing of stdios,
which may not be what we want under panic conditions. Invoking the raw
CloudABI system call would have prevented that.

Unfortunately, we have to make use of the "cloudabi" crate to invoke raw
CloudABI system calls. This is undesired, as discussed in the pull
request (#47190).

CloudABI uses LLVM's libunwind for stack unwinding. There was a small
bug that went by unnoticed, namely that it was not built with -fno-rtti.
This caused it to (indirectly) depend on the entire C++ runtime.

Now that that issue has been resolved, it is also perfectly fine to make
use of this library for programming languages other than C++.

Force appropriate extension when converting from int to ptr #43291

Fixes #43291.

Looking for feedback if I've missed something and/or need to add more tests.

@EddyB @retep998 @nagisa @oli-obk

Reword reason for move note

On move errors, when encountering an enum variant, be more ambiguous and do not refer to the type on the cause note, to avoid referring to `(maybe as std::prelude::v1::Some).0`, and instead refer to `the value`.

Sidesteps part of the problem with #41962:

```
error[E0382]: use of partially moved value: `maybe`
 --> file.rs:5:30
  |
5 |         if let Some(thing) = maybe {
  |                     -----    ^^^^^ value used here after move
  |                     |
  |                     value moved here
  = note: move occurs because the value has type `std::vec::Vec<bool>`, which does not implement the `Copy` trait

error[E0382]: use of moved value: `(maybe as std::prelude::v1::Some).0`
 --> file.rs:5:21
  |
5 |         if let Some(thing) = maybe {
  |                     ^^^^^ value moved here in previous iteration of loop
  = note: move occurs because the value has type `std::vec::Vec<bool>`, which does not implement the `Copy` trait

error: aborting due to 2 previous errors
```

Previous discussion: #44360

r? @arielb1

Limit style lint to non-synthetic generic params

Fix https://github.com/rust-lang/rust/issues/46959

r? @nikomatsakis

NLL fixes

First, introduce pre-statement effects to dataflow to fix #46875. Edge dataflow effects might make that redundant, but I'm not sure of the best way to integrate them with liveness etc., and if this is a hack, this is one of the cleanest hacks I've seen.

And I want a small fix to avoid the torrent of bug reports.

Second, fix linking of projections to fix #46974

r? @pnkfelix

First cut at getting some part of the test suite working for CloudABI

I am currently working on creating a Docker container for automated CI for CloudABI. Here are some of the trivial changes that need to land to make tests pass.

Requested by: kennytm

CStore switch FxHashMap to IndexVec

This is a first attempt to fix #46876.

Rollup of 9 pull requests

- Successful merges: #47104, #47107, #47113, #47117, #47118, #47121, #47125, #47134, #47145
- Failed merges:

Document when LineWriter flushes; document errors for into_inner.

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

Defocus search bar in rustdoc pages

rust-lang/rfcs#2265

Mention SliceConcatExt's stability in its docs

Just saw someone in IRC mention there being no stable way to join string slices! It isn't entirely clear from the rust documentation that `SliceConcatExt` is usable. While this is mentioned in https://doc.rust-lang.org/std/prelude/, the trait has nothing to indicate that it's currently usable if found via a documentation search.

The wording on this could probably be improved, but I'm hoping its better than nothing.

Fix panic condition docs for Vec::insert.

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

memchr: fix variable name in docstrings

upstream BurntSushi/rust-memchr#24

r=BurntSushi

[unstable book] remove duplicate entries

if a unstable feature is a language feature, it shouldn't also have a library feature stub generated

Minor cleanup for slice::Chunks and ChunksMut

This only renames the `size` field to `chunk_size` in one of them for consistency, and changes an assertion to check for != 0 instead of > 0.

Fix typo

I am assuming that there was once something else you could do and somebody forgot to remove "either". Is that correct?

Delay panic from incoherent drop implementation

Closes #41974

Move static code outside of unciode.py.

This script in libstd_unicode is a mess and also contains code that shouldn't be output by a script, and instead just put in modules. So, this change does that.

Only bump error count when we are sure that the diagnostic is not a repetition

This ensures that if we emit the same diagnostic twice, the error count will
match the real number of errors shown to the user.

Fixes #42106

This is a followup of https://github.com/rust-lang/rust/pull/45603 as stated in https://github.com/rust-lang/rust/issues/42106#issuecomment-345218473.

This program, for example:

```rust
fn do_something<T>(collection: &mut Vec<T>) {
    let _a = &collection;
    collection.swap(1, 2);
}

fn main() {}
```

without this patch, produces:

```
error[E0502]: cannot borrow `*collection` as mutable because `collection` is also borrowed as immutable
  --> $DIR/issue-42106.rs:13:5
   |
12 |     let _a = &collection;
   |               ---------- immutable borrow occurs here
13 |     collection.swap(1, 2); //~ ERROR also borrowed as immutable
   |     ^^^^^^^^^^ mutable borrow occurs here
14 | }
   | - immutable borrow ends here

error: aborting due to 2 previous errors
```

The number of errors do not match the diagnostics reported. This PR fixes this problem. The output is now in this case:

```
error[E0502]: cannot borrow `*collection` as mutable because `collection` is also borrowed as immutable
  --> $DIR/issue-42106.rs:13:5
   |
12 |     let _a = &collection;
   |               ---------- immutable borrow occurs here
13 |     collection.swap(1, 2); //~ ERROR also borrowed as immutable
   |     ^^^^^^^^^^ mutable borrow occurs here
14 | }
   | - immutable borrow ends here

error: aborting due to previous error
```

Also, some other tests outputs have been adapted because their count didn't really match the number of diagnostics reported.

As an aside, an outdated comment has been removed (`Handler::cancel` will only call to the `Diagnostic::cancel` method and will not decrease the count of errors).

All tests are passing with this PR (`x.py test` is successful).

This ensures that if we emit the same diagnostic twice, the error count will
match the real number of errors shown to the user.

Fixes #42106

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

Fixed intentaion (tabs -> spaces)
Added trailing newline

Escape now removes focus from the search bar

Due to the disable-cloudabi tags being added to the source files, the
expected output of the compiler is altered slightly.

Delay panic for aliasing violation for static items.

Closes #46604

CloudABI doesn't make any distinction between TTYs and ordinary pipes.
While there, remove the redundant implementation used by Redox. It can
use the same stub function.

CloudABI doesn't support the creation of dynamic libraries. Any test
making use of auxiliary libraries will fail without this change applied.

It looks like many of these tests are already disabled on emscripten,
which also doesn't seem to support environment variables and subprocess
spawning. Just add a similar tag for CloudABI. While there, sort some of
the lists of operating systems alphabetically.

Redox - Implement rename using new system call

This does the following:

- Update syscall module to match upstream
- Implement rename using new system call
- Make readlink and symlink utilize O_CLOEXEC
- Make readlink and symlink not leave dangling file handles on failure

SliceConcatExt's status as an unstable trait with stable methods is
documented in the compiler error for using it, and in
https://doc.rust-lang.org/std/prelude/, but it is not mentioned in the
trait itself.

Mentioning the methods can be used in stable rust today should help
users who are looking for a `join` method while working on stable rust.

Check all repr hints together when checking for mis-applied attributes

Fixes #47094

Besides fixing that bug, this change has a user-visible effect on the spans in the "incompatible repr hints" warning and another error: they now point at `foo` and/or `bar` in `repr(foo, bar)` instead of the whole attribute. This is sometimes more precise (e.g., `#[repr(C, packed)]` on an enum points at the `packed`) but sometimes not. I moved a compile-fail test to a ui test to illustrate how it now looks in the common case of only one attribute.