This PR both adds in-source documentation on what to look out for
when adding a new (X86) feature set and adds all that are detectable at run-time in Rust stable
as of 1.27.0.

This should only enable the use of the corresponding LLVM intrinsics.
Actual intrinsics need to be added separately in rust-lang/stdarch.

It also re-orders the run-time-detect test statements to be more consistent
with the actual list of intrinsics whitelisted and removes underscores not present
in the actual names (which might be mistaken as being part of the name)

`movbe` seems to not be a run-time detectable feature on x86.
It has thus been removed from the list.
It was only commented out to ease comparison against the full list.

…M 9 exclusive features

Updated the added documentation in llvm_util.rs to note which copies of LLVM need to be inspected.
Removed avx512bf16 and avx512vp2intersect because they are unsupported before LLVM 9 with the build with external LLVM 8 being supported
Re-introduced detection testing previously removed for un-requestable features tsc and mmx

With rust-lang#78848 merged, the minimum supported LLVM version is now 9
which means we can actually use the target features introduced in LLVM 9

Historically the stable tarballs were named after the version number of
the specific tool, instead of the version number of Rust. For example,
both of the following tarballs were part of the same release:

    rustc-1.48.0-x86_64-unknown-linux-gnu.tar.xz
    cargo-0.49.0-x86_64-unknown-linux-gnu.tar.xz

PR rust-lang#77336 changed the dist code to instead use Rust's version number for
all the tarballs, regardless of the tool they contain:

    rustc-1.48.0-x86_64-unknown-linux-gnu.tar.xz
    cargo-1.48.0-x86_64-unknown-linux-gnu.tar.xz

Because of that there is no need anymore to have a separate `cargo`
field in src/stage0.txt, as the Cargo version will always be the same as
the rustc version. This PR removes the field, simplifying the code and
the maintenance work required while producing releases.

This should make Clippy more resilient and will unblock rust-lang#78343.

This PR is made against rust-lang/rust to avoid the need for a subtree
sync at @flip1995's suggestion in rust-lang/rust-clippy#6310.

These referred to a “`Write`er”—extra *e*. Presumably a copy-paste
holdover from “`Read`er”.

Test Plan:
Running ``git grep '`\?[Ww]rite`\?er'`` no longer finds any results.

wchargin-branch: io-write-docs

Part of rust-lang#68490.

Care has been taken to leave the old consts where appropriate, for testing backcompat regressions, module shadowing, etc. The intrinsics docs were accidentally referring to some methods on f64 as std::f64, which I changed due to being contrary with how we normally disambiguate the shadow module from the primitive. In one other place I changed std::u8 to std::ops since it was just testing path handling in macros.

For places which have legitimate uses of the old consts, deprecated attributes have been optimistically inserted. Although currently unnecessary, they exist to emphasize to any future deprecation effort the necessity of these specific symbols and prevent them from being accidentally removed.

Updated the list of white-listed target features for x86

This PR both adds in-source documentation on what to look out for when adding a new (X86) feature set and [adds all that are detectable at run-time in Rust stable as of 1.27.0](https://github.com/rust-lang/stdarch/blob/master/crates/std_detect/src/detect/arch/x86.rs).

This should only enable the use of the corresponding LLVM intrinsics.
Actual intrinsics need to be added separately in rust-lang/stdarch.

It also re-orders the run-time-detect test statements to be more consistent
with the actual list of intrinsics whitelisted and removes underscores not present
in the actual names (which might be mistaken as being part of the name)

The reference for LLVM's feature names used is [this file](https://github.com/llvm/llvm-project/blob/master/llvm/include/llvm/Support/X86TargetParser.def).

This PR was motivated as the compiler end's part for allowing rust-lang#67329 to be adressed over on rust-lang/stdarch

… r=jyn514

Update tests to remove old numeric constants

Part of rust-lang#68490.

Care has been taken to leave the old consts where appropriate, for testing backcompat regressions, module shadowing, etc. The intrinsics docs were accidentally referring to some methods on f64 as std::f64, which I changed due to being contrary with how we normally disambiguate the shadow module from the primitive. In one other place I changed std::u8 to std::ops since it was just testing path handling in macros.

For places which have legitimate uses of the old consts, deprecated attributes have been optimistically inserted. Although currently unnecessary, they exist to emphasize to any future deprecation effort the necessity of these specific symbols and prevent them from being accidentally removed.

stability: More precise location for deprecation lint on macros

One missing piece of rust-lang#73178.

Tighten the bounds on atomic Ordering in std::sys::unix::weak::Weak

This moves reading this from multiple SeqCst reads to Relaxed read + Acquire fence if we are actually going to use the data.

Would love to avoid the Acquire fence, but doing so would need Ordering::Consume, which neither Rust, nor LLVM supports (a shame, since this fence is hardly free on ARM, which is what I was hoping to improve).

r? `@Amanieu` (Sorry for always picking you, but I know a lot of people wouldn't feel comfortable reviewing atomic ordering changes)

…sper

Turn top-level comments into module docs in MIR visitor

…eros, r=m-ou-se

add trailing_zeros and leading_zeros to non zero types

as a way towards being able to use the optimized intrinsics ctlz_nonzero and cttz_nonzero from stable.

have not crated any tracking issue if this is not a solution that is wanted

Enable AVX512 *epi64 variants by updating stdarch

…k-Simulacrum

bootstrap: use the same version number for rustc and cargo

Historically the stable tarballs were named after the version number ofthe specific tool, instead of the version number of Rust. For example, both of the following tarballs were part of the same release:

    rustc-1.48.0-x86_64-unknown-linux-gnu.tar.xz
    cargo-0.49.0-x86_64-unknown-linux-gnu.tar.xz

PR rust-lang#77336 changed the dist code to instead use Rust's version number for all the tarballs, regardless of the tool they contain:

    rustc-1.48.0-x86_64-unknown-linux-gnu.tar.xz
    cargo-1.48.0-x86_64-unknown-linux-gnu.tar.xz

Because of that there is no need anymore to have a separate `cargo` field in `src/stage0.txt`, as the Cargo version will always be the same as the rustc version. This PR removes the field, simplifying the code and the maintenance work required while producing releases.

r? `@Mark-Simulacrum`

Fix handling of panic calls

This should make Clippy more resilient and will unblock rust-lang#78343.

This PR is made against rust-lang/rust to avoid the need for a subtree
sync at `@flip1995's` suggestion in rust-lang/rust-clippy#6310.

r? `@flip1995`
cc `@m-ou-se`

…jyn514

Fix typo in `std::io::Write` docs

These referred to a “`Write`er”—extra *e*. Presumably a copy-paste
holdover from “`Read`er”.

Test Plan:
Running ``git grep '`\?[Ww]rite`\?er'`` no longer finds any results.

wchargin-branch: io-write-docs

type is too big -> values of the type are too big

strictly speaking, `[u8; usize::MAX]` or even `[[[u128; usize::MAX]; usize::MAX]; usize::MAX]` are absolutely fine types as long as you don't try to deal with any values of it.

This error message seems to cause some confusion imo, for example in rust-lang#79135 (comment) so I would prefer us to be more precise here.

See the added test case which uses one of these types without causing an error.

r? `@oli-obk`