Tweak some warnings around #[target_feature]

This commit fixes up some issues discovered when getting the `stdsimd` crate's CI compiling again.

Fix the miri tool

r? @EddyB

cc @bjorn3

fixes #49777

Android abstract unix domain sockets AddressKind correction

The prior check causes abstract unix domain sockets to return AddressKind::Unnamed instead of AddressKind::Abstract on Android.

Other than the immediately proceeding comment "macOS seems to return a len of 16 and a zeroed sun_path for unnamed addresses" the check as-implemented does not seem to have alternative explanation. I couldn't find an alternative explanation while stepping though git blame. I suspect the AddressKind::Unnamed nonzero check should instead be if macos, length 16, and zeroed array. @sfackler could you comment on this, the code as-is is the same from your initial addition of abstract uds support.

Don't allow #[should_panic] with non-() tests

Adds (removes) support for `#[should_panic]` when the test is non-`()`

work towards chalkify-ing the engine

This work towards creating a "all program clauses needed for this goal" query

r? @scalexm

Rollup of 11 pull requests

Successful merges:

 - #49461 (std: Child::kill() returns error if process has already exited)
 - #49727 (Add Cell::update)
 - #49812 (Fix revision support for UI tests.)
 - #49829 (Add doc links to `std::os` extension traits)
 - #49906 (Stabilize `std::hint::unreachable_unchecked`.)
 - #49970 (Deprecate Read::chars and char::decode_utf8)
 - #49985 (don't see issue #0)
 - #50118 (fix search bar bug)
 - #50139 (encourage descriptive issue titles)
 - #50174 (Use FxHashMap in syntax_pos::symbol::Interner::intern.)
 - #50185 (core: Fix overflow in `int::mod_euc` when `self < 0 && rhs == MIN`)

Failed merges:

core: Fix overflow in `int::mod_euc` when `self < 0 && rhs == MIN`

This commit removes usage of `abs`, which overflows when `self == MIN`.

Use FxHashMap in syntax_pos::symbol::Interner::intern.

Because it's faster than HashMap.

This change reduces the time taken for a few of the rustc-perf
benchmarks, mostly the small ones, by up to 5%.
```
coercions
        avg: -1.3%      min: -5.5%      max: -0.0%
helloworld-check
        avg: -2.3%      min: -3.5%      max: -1.8%
deeply-nested-check
        avg: -1.4%      min: -3.2%      max: -0.5%
tuple-stress-opt
        avg: -0.7%      min: -2.0%      max: -0.1%
unify-linearly-check
        avg: -1.2%      min: -1.9%      max: -0.6%
coercions-check
        avg: -0.8%      min: -1.3%      max: -0.4%
unused-warnings-check
        avg: -1.0%      min: -1.3%      max: -0.8%
deeply-nested-opt
        avg: -0.5%      min: -1.2%      max: -0.2%
deeply-nested
        avg: -0.7%      min: -1.2%      max: -0.4%
helloworld
        avg: -0.8%      min: -1.1%      max: -0.7%
tuple-stress-check
        avg: -0.5%      min: -1.0%      max: -0.1%
unused-warnings
        avg: -0.8%      min: -1.0%      max: -0.7%
unused-warnings-opt
        avg: -0.8%      min: -1.0%      max: -0.7%
coercions-opt
        avg: -0.5%      min: -1.0%      max: -0.1%
helloworld-opt
        avg: -0.7%      min: -1.0%      max: -0.6%
```

encourage descriptive issue titles

There are two sides to avoiding duplicate issues, searching for existing ones, and making sure existing ones can be searched for. This addresses the later.

r? @steveklabnik

fix search bar bug

Fixes #50064.

r? @QuietMisdreavus

don't see issue #0

The unstable-feature attribute requires an issue (neglecting it is
E0547), which gets used in the error messages. Unfortunately, there are
some cases where "0" is apparently used a placeholder where no issue
exists, directing the user to see the (nonexistent) issue #0. (It would
have been better to either let `issue` be optional—compare to how issue
is an `Option<u32>` in the feature-gate declarations in
libsyntax/feature-gate.rs—or actually require that an issue be created.)
Rather than endeavoring to change how `#[unstable]` works at this time
(given competing contributor and reviewer priorities), this simple patch
proposes the less-ambitious solution of just not adding the "(see
issue)" note when the number is zero.

Resolves #49983.

Deprecate Read::chars and char::decode_utf8

Per FCP:

* https://github.com/rust-lang/rust/issues/27802#issuecomment-377537778
* https://github.com/rust-lang/rust/issues/33906#issuecomment-377534308

Stabilize `std::hint::unreachable_unchecked`.

Closes #43751.

Add doc links to `std::os` extension traits

Addresses a small subset of #29367.

This adds documentation links to the original type for various OS-specific extension traits, and uses a common sentence for introducing such traits (which now consistently ends in a period).

Fix revision support for UI tests.

Fixes #48878

Add Cell::update

This commit adds a new method `Cell::update`, which applies a function to the value inside the cell.

Previously discussed in: https://github.com/rust-lang/rfcs/issues/2171

### Motivation

Updating `Cell`s is currently a bit verbose. Here are several real examples (taken from rustc and crossbeam):

```rust
self.print_fuel.set(self.print_fuel.get() + 1);

self.diverges.set(self.diverges.get() | Diverges::Always);

let guard_count = self.guard_count.get();
self.guard_count.set(guard_count.checked_add(1).unwrap());
if guard_count == 0 {
    // ...
}
```

With the addition of the new method `Cell::update`, this code can be simplified to:

```rust
self.print_fuel.update(|x| x + 1);

self.diverges.update(|x| x | Diverges::Always);

if self.guard_count.update(|x| x.checked_add(1).unwrap()) == 1 {
    // ...
}
```

### Unresolved questions

1. Should we return the old value instead of the new value (like in `fetch_add` and `fetch_update`)?
2. Should the return type simply be `()`?
3. Naming: `update` vs `modify` vs `mutate` etc.

cc @SimonSapin

std: Child::kill() returns error if process has already exited

This patch makes it clear in std::process::Child::kill()'s API
documentation that an error is returned if the child process has
already cleanly exited.  This is implied by the example, but not
called out explicitly.

Add repeat method on slice

Fixes #48784.

Make signature of Path::strip_prefix accept non-references

I did this a while back but didn't submit a PR. Might as well see what happens.

Fixes #48390.

**Note: This has the potential to cause regressions in type inference.**  However, in order for code to break, it would need to be relying on the signature to determine that a type is `&_`, while still being able to figure out what the `_` is.  I'm having a hard time imagining such a scenario in real code.

Don't report compile-time errors for promoteds

Fixes the regression part of #49760, the missing warnings still are missing

r? @EddyB

Feature gate where clauses on associated types

Fixes #49365. Requires crater: these have been usable since 1.24.

Also, introduce `Clauses` and `Goals` type alises for readability.

This computes the transitive closure of traits that appear in the
environment and then appends their clauses. It needs some work, but
it's in the right direction.

(rather than issuing multiple errors)

Also, reorder so that the annotations are considered "used" when the
lint runs.

Chalk wants to be able to pass these constraints around. Also, the
form we were using in our existing queries was not as general as we
are going to need.

Better error message when trying to write default impls

Previously, if you tried to write this (using the specialization
feature flag):

default impl PartialEq<MyType> {
...
}

The compiler would give you the mysterious warning "inherent impls
cannot be default". What it really means is that you're trying to
write an impl for a Structure or *Trait Object*, and that cannot
be "default". However, one of the ways to encounter this error
(as shown by the above example) is when you forget to write "for
MyType".

This PR adds a help message that reads "maybe missing a `for`
keyword?" This is useful, actionable advice that will help any user
identify their mistake, and doesn't get in the way or mislead any
user that really meant to use the "default" keyword for this weird
purpose. In particular, this help message will be useful for any
users who don't know the "inherent impl" terminology, and/or users
who forget that inherent impls CAN be written for traits (they apply
to the trait objects). Both of these are somewhat confusing, seldom-
used concepts; a one-line error message without any error number for
longer explanation is NOT the place to introduce these ideas.

I wasn't quite sure what grammar / wording to use. I'm open to suggestions. CC @rust-lang/docs (I hope I'm doing that notation right)

(Apparently not. :( )

Because it's faster than HashMap.

This change reduces the time taken for a few of the rustc-perf
benchmarks, mostly the small ones, by up to 5%.