Unix RwLock: avoid racy access to write_locked

We should only access `write_locked` if we really got the lock.

Rewrite `...` as `..=` as a `MachineApplicable` 2018 idiom lint

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

Add mem::forget_unsized() for forgetting unsized values

~~Allows passing values of `T: ?Sized` types to `mem::drop` and `mem::forget`.~~

Adds `mem::forget_unsized()` that accepts `T: ?Sized`.

I had to revert the PR that removed the `forget` intrinsic and replaced it with `ManuallyDrop`: https://github.com/rust-lang/rust/pull/40559
We can't use `ManuallyDrop::new()` here because it needs `T: Sized` and we don't have support for unsized return values yet (will we ever?).

r? @EddyB

Rollup merge of #55781 - pnkfelix:issue-54382-more-precise-spans-for-temps-and-their-drops, r=davidtwco

More precise spans for temps and their drops

This PR has two main enhancements:

 1. when possible during code generation for a statement (like `expr();`), pass along the span of a statement, and then attribute the drops of temporaries from that statement to the statement's end-point (which will be the semicolon if it is a statement that is terminating by a semicolon).
 2. when evaluating a block expression into a MIR temp, use the span of the block's tail expression (rather than the span of whole block including its statements and curly-braces) for the span of the temp.

Each of these individually increases the precision of our diagnostic output; together they combine to make a much clearer picture about the control flow through the spans.

Fix #54382

Wrap some query results in `Lrc`.

So that the frequent clones in `try_get` are cheaper.

Make `NodeId` and `HirLocalId` `newtype_index`

NetBSD: link libstd with librt in addition to libpthread

Some aio(3) and mq(3) functions in the libc crate actually come from NetBSD librt, not libc or libpthread.

Use `Mmap` to open the rmeta file.

Because those files are quite large, contribute significantly to peak
memory usage, but only a small fraction of the data is ever read.

r? @EddyB

Speed up String::from_utf16

Collecting into a `Result` is idiomatic, but not necessarily fast due to rustc not being able to preallocate for the resulting collection. This is fine in case of an error, but IMO we should optimize for the common case, i.e. a successful conversion.

This changes the behavior of `String::from_utf16` from collecting into a `Result` to pushing to a preallocated `String` in a loop.

According to [my simple benchmark](https://gist.github.com/ljedrz/953a3fb74058806519bd4d640d6f65ae) this change makes `String::from_utf16` around **twice** as fast.

Add link to std::mem::size_of to size_of intrinsic documentation

The other intrinsics with safe/stable alternatives already have documentation to this effect.

Add BufWriter::buffer method

CC #45323

Redox: Update to new changes

These are all cherry-picked from our fork:

 - Remove the `env:` scheme
 - Update `execve` system call to `fexec`
 - Interpret shebangs: these are no longer handled by the kernel, which like usual tries to be as minimal as possible

Add escape-to-raw MIR statement

Add a new MIR "ghost state statement": Escaping a ptr to permit raw accesses.

~~This includes #55549, [click here](https://github.com/RalfJung/rust/compare/miri-visitor...RalfJung:escape-to-raw) for just the new commits.~~

std: Synchronize access to global env during `exec`

This commit, after reverting #55359, applies a different fix for #46775
while also fixing #55775. The basic idea was to go back to pre-#55359
libstd, and then fix #46775 in a way that doesn't expose #55775.

The issue described in #46775 boils down to two problems:

* First, the global environment is reset during `exec` but, but if the
  `exec` call fails then the global environment was a dangling pointer
  into free'd memory as the block of memory was deallocated when
  `Command` is dropped. This is fixed in this commit by installing a
  `Drop` stack object which ensures that the `environ` pointer is
  preserved on a failing `exec`.

* Second, the global environment was accessed in an unsynchronized
  fashion during `exec`. This was fixed by ensuring that the
  Rust-specific environment lock is acquired for these system-level
  operations.

Thanks to Alex Gaynor for pioneering the solution here!

Closes #55775

This commit, after reverting #55359, applies a different fix for #46775
while also fixing #55775. The basic idea was to go back to pre-#55359
libstd, and then fix #46775 in a way that doesn't expose #55775.

The issue described in #46775 boils down to two problems:

* First, the global environment is reset during `exec` but, but if the
  `exec` call fails then the global environment was a dangling pointer
  into free'd memory as the block of memory was deallocated when
  `Command` is dropped. This is fixed in this commit by installing a
  `Drop` stack object which ensures that the `environ` pointer is
  preserved on a failing `exec`.

* Second, the global environment was accessed in an unsynchronized
  fashion during `exec`. This was fixed by ensuring that the
  Rust-specific environment lock is acquired for these system-level
  operations.

Thanks to Alex Gaynor for pioneering the solution here!

Closes #55775
Co-authored-by: NAlex Gaynor <alex.gaynor@gmail.com>

xLTO: Don't pass --plugin-opt=thin to LLD. That's not supported anymore.

It seems that `-plugin-opt=thin` is not needed anymore when invoking LLD for ThinLTO. Unfortunately, still passing the option makes LLD crash instead of giving a deprecation warning or something.

This reverts commit 36fe3b60.

Switch AppVeyor builds to the GCE cloud

[Recommended by AppVeyor][1] this isn't done by default for all builds
due to the high startup overhead (3-4 minutes for a VM), but that's
paltry compared to our overall build times so should be more than
applicable!

[1]: https://help.appveyor.com/discussions/questions/29832-did-recent-changes-apply-to-possibly-slow-down-builds#comment_46494058

Because those files are quite large, contribute significantly to peak
memory usage, but only a small fraction of the data is ever read.

chalk lowering rule: ProjectionEq-Normalize

cc #49177
r? @scalexm

So that the frequent clones in `try_get` are cheaper.

Fixes #54274.

Rollup of 20 pull requests

Successful merges:

 - #55136 (Remove short doc where it starts with a codeblock)
 - #55711 (Format BtreeMap::range_mut example)
 - #55722 (impl_stable_hash_for: support enums and tuple structs with generic parameters)
 - #55754 (Avoid converting bytes to UTF-8 strings to print, just pass bytes to stdout/err)
 - #55804 (rustdoc: don't inline `pub use some_crate` unless directly asked to)
 - #55805 (Move `static_assert!` into librustc_data_structures)
 - #55837 (Make PhantomData #[structural_match])
 - #55840 (Fix TLS errors when downloading stage0)
 - #55843 (add FromIterator<A> to Box<[A]>)
 - #55858 (Small fixes on code blocks in rustdoc)
 - #55863 (Fix a typo in std::panic)
 - #55870 (Fix typos.)
 - #55874 (string: Add documentation for `From` impls)
 - #55879 (save-analysis: Don't panic for macro-generated use globs)
 - #55882 (Reference count `crate_inherent_impls`s return value.)
 - #55888 (miri: for uniformity, also move memory_deallocated to AllocationExtra)
 - #55889 (global allocators: add a few comments)
 - #55896 (Document optimizations enabled by FusedIterator)
 - #55905 (Change `Lit::short_name` to `Lit::literal_name`.)
 - #55908 (Fix their/there grammar nit)

[Recommended by AppVeyor][1] this isn't done by default for all builds
due to the high startup overhead (3-4 minutes for a VM), but that's
paltry compared to our overall build times so should be more than
applicable!

[1]: https://help.appveyor.com/discussions/questions/29832-did-recent-changes-apply-to-possibly-slow-down-builds#comment_46494058

Check for negative impls when finding auto traits

Fixes #55321

When AutoTraitFinder begins examining a type, it checks for an explicit
negative impl. However, it wasn't checking for negative impls found when
calling 'select' on predicates found from nested obligations.

This commit makes AutoTraitFinder check for negative impls whenever it
makes a call to 'select'. If a negative impl is found, it immediately
bails out.

Normal users of SelectioContext don't need to worry about this, since
they stop as soon as an Unimplemented error is encountered. However, we
add predicates to our ParamEnv when we encounter this error, so we need
to handle negative impls specially (so that we don't try adding them to
our ParamEnv).

Use bound types in `librustc_traits`

r? @nikomatsakis
see the tests which now move the higher-ranked binders to the left in implied bound rules!

A `WF(Type)` predicate was used previously, which did not play
well with implied bounds in chalk.

impl_stable_hash_for: support enums and tuple structs with generic parameters

Port a bunch of implementations over to the macro, now that that is possible.

Remove short doc where it starts with a codeblock

Fixes #54975.

Fix their/there grammar nit