Rollup of 10 pull requests #126655
Merged
Rollup of 10 pull requests #126655
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
Previously, `Tree::from_enum`'s implementation branched into three disjoint
cases:
1. enums that uninhabited
2. enums for which all but one variant is uninhabited
3. enums with multiple inhabited variants
This branching (incorrectly) did not differentiate between variantful and
variantless uninhabited enums. In both cases, we assumed (and asserted) that
uninhabited enums are zero-sized types. This assumption is false for enums like:
enum Uninhabited { A(!, u128) }
...which, currently, has the same size as `u128`. This faulty assumption
manifested as the ICE reported in rust-lang#126460.
In this PR, we revise the first case of `Tree::from_enum` to consider only the
narrow category of "enums that are uninhabited ZSTs". These enums, whose layouts
are described with `Variants::Single { index }`, are special in their layouts
otherwise resemble the `!` type and cannot be descended into like typical enums.
This first case captures uninhabited enums like:
enum Uninhabited { A(!, !), B(!) }
The second case is revised to consider the broader category of "enums that defer
their layout to one of their variants"; i.e., enums whose layouts are described
with `Variants::Single { index }` and that do have a variant at `index`. This
second case captures uninhabited enums that are not ZSTs, like:
enum Uninhabited { A(!, u128) }
...which represent their variants with `Variants::Single`.
Finally, the third case is revised to cover the broader category of "enums with
multiple variants", which captures uninhabited, non-ZST enums like:
enum Uninhabited { A(u8, !), B(!, u32) }
...which represent their variants with `Variants::Multiple`.
This PR also adds a comment requested by RalfJung in his review of rust-lang#126358 to
`compiler/rustc_const_eval/src/interpret/discriminant.rs`.
Fixes rust-lang#126460
This synchronizes the fuchsia test running code with the clang test runner. This brings with it: * Improved logging * Uses the fuchsia image from the SDK version * Caches the product bundle across test runs * Strips the binaries to reduce the data sent to the emulator
Edit from rust-lang#126631 to revert changes on ui tests
…ram" note - Avoid "caller chooses ty for type param" note if the found type a.k.a. the return expression type *contains* the type parameter, because e.g. `&T` will always be different from `T` (i.e. "well duh"). - Rename `note_caller_chooses_ty_for_ty_param` to `try_note_caller_chooses_ty_for_ty_param` because the note is not always made. Issue: rust-lang#126547
delegation: Implement glob delegation Support delegating to all trait methods in one go. Overriding globs with explicit definitions is also supported. The implementation is generally based on the design from rust-lang/rfcs#3530 (comment), but unlike with list delegation in rust-lang#123413 we cannot expand glob delegation eagerly. We have to enqueue it into the queue of unexpanded macros (most other macros are processed this way too), and then a glob delegation waits in that queue until its trait path is resolved, and enough code expands to generate the identifier list produced from the glob. Glob delegation is only allowed in impls, and can only point to traits. Supporting it in other places gives very little practical benefit, but significantly raises the implementation complexity. Part of rust-lang#118212.
…errors fix: break inside async closure has incorrect span for enclosing closure Fixes rust-lang#124496
…fetime, r=estebank,davidtwco Place tail expression behind terminating scope This PR implements rust-lang#123739 so that we can do further experiments in nightly. A little rewrite has been applied to `for await` lowering. It was previously `unsafe { Pin::unchecked_new(into_async_iter(..)) }`. Under the edition 2024 rule, however, `into_async_iter` gets dropped at the end of the `unsafe` block. This presumably the first Edition 2024 migration rule goes by hoisting `into_async_iter(..)` into `match` one level above, so it now looks like the following. ```rust match into_async_iter($iter_expr) { ref mut iter => match unsafe { Pin::unchecked_new(iter) } { ... } } ```
…r=fmease Suggest using a standalone doctest for non-local impl defs This PR tweaks the lint output of the `non_local_definitions` lint to suggest using a standalone doctest instead of a moving the `impl` def to an impossible place as was already done with `macro_rules!` case in rust-lang#124568. Fixes rust-lang#126339 r? ```@fmease```
safe transmute: support non-ZST, variantful, uninhabited enums
Previously, `Tree::from_enum`'s implementation branched into three disjoint cases:
1. enums that uninhabited
2. enums for which all but one variant is uninhabited
3. enums with multiple variants
This branching (incorrectly) did not differentiate between variantful and variantless uninhabited enums. In both cases, we assumed (and asserted) that uninhabited enums are zero-sized types. This assumption is false for enums like:
enum Uninhabited { A(!, u128) }
...which, currently, has the same size as `u128`. This faulty assumption manifested as the ICE reported in rust-lang#126460.
In this PR, we revise the first case of `Tree::from_enum` to consider only the narrow category of "enums that are uninhabited ZSTs". These enums, whose layouts are described with `Variants::Single { index }`, are special in their layouts otherwise resemble the `!` type and cannot be descended into like typical enums. This first case captures uninhabited enums like:
enum Uninhabited { A(!, !), B(!) }
The second case is revised to consider the broader category of "enums that defer their layout to one of their variants"; i.e., enums whose layouts are described with `Variants::Single { index }` and that do have a variant at `index`. This second case captures uninhabited enums that are not ZSTs, like:
enum Uninhabited { A(!, u128) }
...which represent their variants with `Variants::Single`.
Finally, the third case is revised to cover the broader category of "enums with multiple variants", which captures uninhabited enums like:
enum Uninhabited { A(u8, !), B(!, u32) }
...which represent their variants with `Variants::Multiple`.
This PR also adds a comment requested by ````@RalfJung```` in his review of rust-lang#126358 to `compiler/rustc_const_eval/src/interpret/discriminant.rs`.
Fixes rust-lang#126460
r? ````@compiler-errors````
Sync fuchsia test runner with clang test runner This synchronizes the fuchsia test running code with the clang test runner. This brings with it: * Improved logging * Uses the fuchsia image from the SDK version * Caches the product bundle across test runs * Strips the binaries to reduce the data sent to the emulator r? ``@tmandry``
hir_typeck: be more conservative in making "note caller chooses ty param" note In rust-lang#122195 I added a "caller chooses ty for type param" note for when the return expression type a.k.a. found type does not match the expected return type. rust-lang#126547 found that this note was confusing when the found return type *contains* the expected type, e.g. ```rs fn f<T>(t: &T) -> T { t } ``` because the found return type `&T` will *always* be different from the expected return type `T`, so the note was needlessly redundant and confusing. This PR addresses that by not making the note if the found return type contains the expected return type. r? ``@fmease`` (since you reviewed the original PR) Fixes rust-lang#126547
…r=Nilstrieb Add @badboy and @BlackHoleFox as Mac Catalyst maintainers Assented in rust-lang/compiler-team#761 (comment) and https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Promote.20Mac.20Catalyst.20targets.20to.20Tier.202.20compiler-team.23761/near/444590303.
…-errors
Add `rustc-ice*` to `.gitignore`
I am a bit surprised this wasn't already here but there doesn't seem to be any reason not to add it. This will be nice to cut down on `git {add, diff, etc}` noise when debugging crashes.
…-v2, r=Nilstrieb Replace `move||` with `move ||` Edit from rust-lang#126631 to revert changes in `tests/ui`. There are 18 instances of `move||` across 6 files in the repo: - `compiler/rustc_hir_typeck/src/typeck_root_ctxt.rs` - `library/core/src/sync/atomic.rs` - `library/std/src/sync/condvar.rs` - `library/std/src/sync/mpsc/mod.rs` - `library/std/src/sync/barrier.rs` - `library/std/src/thread/local.rs` I have replaced all such instances with `move ||` instead as it better adheres to modern formatting standards. Ideally, we would have this automated by rustfmt or some other tool, but I do not have the time to implement such a feature or tool. Nonetheless, I would encourage any effort invested into such a tool or feature.
rustbot
added
A-testsuite
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 4e63822fc4 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Jun 19, 2024
|
Finished benchmarking commit (a1ca449): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)Results (primary -1.6%)This 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.
CyclesResults (primary -2.3%, secondary -3.8%)This 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 sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 690.013s -> 691.468s (0.21%) |
Mark-Simulacrum
added
the
perf-regression-triaged
|
Marking as triaged, regressions look like they're mostly spurious -- seems to have bounced back in the next few commits. |
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:
rustc-ice*to.gitignore#126615 (Addrustc-ice*to.gitignore)move||withmove ||#126632 (Replacemove||withmove ||)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup