Rollup of 6 pull requests #95223
Merged
Rollup of 6 pull requests #95223
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
- The edition should be 2021 to avoid warnings. - The `external_crate` feature was removed in commit 45bf1ed ("rustc: Allow changing the default allocator"). Note that commit d620ae1 ("Auto merge of rust-lang#84266") removed the old test, but the new one introduced passed the `--cfg` like in the old one. Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Arm's FEAT_FP and Feat_AdvSIMD describe the same thing on AArch64: The Neon unit, which handles both floating point and SIMD instructions. Moreover, a configuration for AArch64 must include both or neither. Arm says "entirely proprietary" toolchains may omit floating point: https://developer.arm.com/documentation/102374/0101/Data-processing---floating-point In the Programmer's Guide for Armv8-A, Arm says AArch64 can have both FP and Neon or neither in custom implementations: https://developer.arm.com/documentation/den0024/a/AArch64-Floating-point-and-NEON In "Bare metal boot code for Armv8-A", enabling Neon and FP is just disabling the same trap flag: https://developer.arm.com/documentation/dai0527/a In an unlikely future where "Neon and FP" become unrelated, we can add "[+-]fp" as its own feature flag. Until then, we can simplify programming with Rust on AArch64 by folding both into "[+-]neon", which is valid as it supersets both. "[+-]neon" is retained for niche uses such as firmware, kernels, "I just hate floats", and so on.
Adds regression tests for feature logic Co-authored-by: bjorn3 <bjorn3@users.noreply.github.com> Co-authored-by: Simonas Kazlauskas <git@kazlauskas.me>
Required by rust-lang#95002
…sa,Amanieu Fold aarch64 feature +fp into +neon Arm's FEAT_FP and Feat_AdvSIMD describe the same thing on AArch64: The Neon unit, which handles both floating point and SIMD instructions. Moreover, a configuration for AArch64 must include both or neither. Arm says "entirely proprietary" toolchains may omit floating point: https://developer.arm.com/documentation/102374/0101/Data-processing---floating-point In the Programmer's Guide for Armv8-A, Arm says AArch64 can have both FP and Neon or neither in custom implementations: https://developer.arm.com/documentation/den0024/a/AArch64-Floating-point-and-NEON In "Bare metal boot code for Armv8-A", enabling Neon and FP is just disabling the same trap flag: https://developer.arm.com/documentation/dai0527/a In an unlikely future where "Neon and FP" become unrelated, we can add "[+-]fp" as its own feature flag. Until then, we can simplify programming with Rust on AArch64 by folding both into "[+-]neon", which is valid as it supersets both. "[+-]neon" is retained for niche uses such as firmware, kernels, "I just hate floats", and so on. I am... pretty sure no one is relying on this. An argument could be made that, as we are not an "entirely proprietary" toolchain, we should not support AArch64 without floats at all. I think that's a bit excessive. However, I want to recognize the intent: programming for AArch64 should be simplified where possible. For x86-64, programmers regularly set up illegal feature configurations because it's hard to understand them, see rust-lang#89586. And per the above notes, plus the discussion in rust-lang#86941, there should be no real use cases for leaving these features split: the two should in fact always go together. - Fixes rust-lang#95002. - Fixes rust-lang#95064. - Fixes rust-lang#95122.
add perf side effect docs to `Iterator::cloned()` Now that rust-lang#90209 has been closed, as the current state of affairs is neither here nor there, this at least adds a paragraph + example on what to expect performance-wise and how to deal with it to the .cloned() docs. cc `@the8472`
…ottmcm Add u16::is_utf16_surrogate Right now, there are methods in the standard library for encoding and decoding UTF-16, but at least for the moment, there aren't any methods specifically for `u16` to help work with UTF-16 data. Since the full logic already exists, this wouldn't really add any code, just expose what's already there. This method in particular is useful for working with the data returned by Windows `OsStrExt::encode_wide`. Initially, I was planning to also offer a `TryFrom<u16> for char`, but decided against it for now. There is plenty of code in rustc that could be rewritten to use this method, but I only checked within the standard library to replace them. I think that offering more UTF-16-related methods to u16 would be useful, but I think this one is a good start. For example, one useful method might be `u16::is_pattern_whitespace`, which would check if something is the Unicode `Pattern_Whitespace` category. We can get away with this because all of the `Pattern_Whitespace` characters are in the basic multilingual plane, and hence we don't need to check for surrogates.
…s-create-snapshot-for-diagnostic, r=Dylan-DPC Replace `this.clone()` with `this.create_snapshot_for_diagnostic()` Use [`create_snapshot_for_diagnostic`](https://github.com/rust-lang/rust/blob/cd119057160cedea245aa2679add56723f3dc784/compiler/rustc_parse/src/parser/diagnostics.rs#L214-L223) I implemented in rust-lang#94731 instead of `this.clone()` to avoid duplicate errors about unclosed delims being emitted when the `Parser` is dropped.
…test, r=Dylan-DPC Modernize `alloc-no-oom-handling` test - The edition should be 2021 to avoid warnings. - The `external_crate` feature was removed in commit 45bf1ed ("rustc: Allow changing the default allocator"). Note that commit d620ae1 ("Auto merge of rust-lang#84266") removed the old test, but the new one introduced passed the `--cfg` like in the old one. Signed-off-by: Miguel Ojeda <ojeda@kernel.org> --- This is intended to align this test to the new `no_rc` and `no_sync` ones being added in rust-lang#89891, but it makes sense on its own too.
interpret/validity: improve clarity I was confused by my own (ancient) comment in `validity.rs` so I figured I'd clarify. (And I don't think ZST-ness is relevant at all inside that branch, no idea where that comment comes from.) Also `extend` seems more clear than `clone_from`.
rustbot
added
T-compiler
|
@bors r+ rollup=never p=5 |
|
📌 Commit 2f24923 has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (7b0bf9e): comparison url. Summary: This benchmark run did not return any relevant results. 2 results were found to be statistically significant but too small to be relevant. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
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:
Iterator::cloned()#92955 (add perf side effect docs toIterator::cloned())this.clone()withthis.create_snapshot_for_diagnostic()#95212 (Replacethis.clone()withthis.create_snapshot_for_diagnostic())alloc-no-oom-handlingtest #95219 (Modernizealloc-no-oom-handlingtest)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup