Rollup of 11 pull requests #79165
Closed
Rollup of 11 pull requests #79165
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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`
|
@bors r+ p=11 rollup=never |
|
📌 Commit 97cd4c4 has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit 97cd4c4 with merge 092b2f70dacc39e053efbd1159117269a93cae69... |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
std::io::Writedocs #79151 (Fix typo instd::io::Writedocs)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup