Rollup of 8 pull requests #120877
Merged
Rollup of 8 pull requests #120877
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
Add documentation about a current footgun of `str::starts_with`
The documentation for atomic integers says that they have the "same in-memory representation" as their underlying integers. This might be misconstrued as implying that they have the same layout. Therefore, clarify that atomic integers' alignment is equal to their size.
The meaning of this assertion changed in rust-lang#120828 when the meaning of `has_errors` changed to exclude stashed errors. Evidently the new meaning is too restrictive. Fixes rust-lang#120856.
Implementing traits marked with `#[rustc_specialization_trait]` normally requires (min-)specialization to be enabled for the enclosing crate. With this change, that permission can also be granted by an `allow_internal_unstable` attribute on the macro that generates the impl.
These crates all needed specialization for `newtype_index!`, which will no longer be necessary when the current nightly eventually becomes the next bootstrap compiler.
…wco,oli-obk static mut: allow mutable reference to arbitrary types, not just slices and arrays For historical reasons, we allow this: ```rust static mut ARRAY: &'static mut [isize] = &mut [1]; ``` However, we do not allow this: ```rust static mut INT: &'static mut isize = &mut 1; ``` I think that's terribly inconsistent. I don't care much for `static mut`, but we have to keep it around for backwards compatibility and so we have to keep supporting it properly in the compiler. In recent refactors of how we deal with mutability of data in `static` and `const`, I almost made a fatal mistake since I tested `static mut INT: &'static mut isize = &mut 1` and concluded that we don't allow such `'static` mutable references even inside `static mut`. After all, nobody would expect this to be allowed only for arrays and slices, right?!?? So for the sake of our own sanity, and of whoever else reverse engineers these rules in the future to understand what the Rust compiler accepts or does not accept, I propose that we accept this for all types, not just arrays and slices.
Remove support for `associated_type_bound` nested in `dyn` types These necessarily desugar to `impl Trait`, which is inconsistent with the `associated_type_bound` feature after rust-lang#120584. This PR keeps the `is_in_dyn_type` hack, which kind of makes me sad. Ideally, we'd be validating that no object types have associated type bounds somewhere else. Unfortunately, we can't do this later during astconv (i think?), nor can we do it earlier during ast validation (i think?) because of the feature gating of ATB being a *warning* rather than an *error*. Let me know if you have thoughts about this. r? lcnr
Add documentation on `str::starts_with` Add documentation about a current footgun of `str::starts_with`
…gn, r=RalfJung Clarify that atomic and regular integers can differ in alignment The documentation for atomic integers says that they have the "same in-memory representation" as their underlying integers. This might be misconstrued as implying that they have the same layout. Therefore, clarify that atomic integers' alignment is equal to their size.
Loosen an assertion to account for stashed errors. The meaning of this assertion changed in rust-lang#120828 when the meaning of `has_errors` changed to exclude stashed errors. Evidently the new meaning is too restrictive. Fixes rust-lang#120856. r? ```@oli-obk```
…rcote Turn the "no saved object file in work product" ICE into a translatable fatal error I don't know if it's fair to say this fixes rust-lang#120854 but it surely makes the error reporting better and should encourage people with good instincts like ```@CinchBlue.```
…rrors Remove unnecessary `#![feature(min_specialization)]` As of rust-lang#119963 and rust-lang#120676, we can now rely on `newtype_index!` having `#[allow_internal_unstable(min_specialization)]`, so there are a few compiler crates that no longer need to include min-spec in their own crate features. --- Some of the expansions of `newtype_index!` still appear to require min-spec in the crate features. I think this is because `#[orderable]` causes the expansion to include an implementation of `TrustedStep`, which is flagged with `#[rustc_specialization_trait]`, and for whatever reason that isn't permitted by allow-internal-unstable. So this PR only touches the crates where that isn't the case.
Allow restricted trait impls under `#[allow_internal_unstable(min_specialization)]` This is a follow-up to rust-lang#119963 and a companion to rust-lang#120866, though it can land independently from the latter. --- We have several compiler crates that only enable `#[feature(min_specialization)]` because it is required by their expansions of `newtype_index!`, in order to implement traits marked with `#[rustc_specialization_trait]`. This PR allows those traits to be implemented internally by macros with `#[allow_internal_unstable(min_specialization)]`, without needing specialization to be enabled in the enclosing crate.
rustbot
added
S-waiting-on-review
|
@bors r+ rollup=never p=8 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 232919c33a In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Feb 10, 2024
|
Finished benchmarking commit (5f40394): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 666.159s -> 666.587s (0.06%) |
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:
associated_type_boundnested indyntypes #120719 (Remove support forassociated_type_boundnested indyntypes)str::starts_with#120764 (Add documentation onstr::starts_with)#![feature(min_specialization)]#120866 (Remove unnecessary#![feature(min_specialization)])#[allow_internal_unstable(min_specialization)]#120870 (Allow restricted trait impls under#[allow_internal_unstable(min_specialization)])r? @ghost
@rustbot modify labels: rollup
Create a similar rollup