Rollup of 20 pull requests #126653
Closed
Rollup of 20 pull requests #126653
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
Apparently MIR borrowck cares about at least one of these for checking variance. In runtime MIR, though, there's no need for them as `PtrToPtr` does the same thing. (Banning them simplifies passes like GVN that no longer need to handle multiple cast possibilities.)
We can't mix them with candidates below them, but we can mix them with candidates above.
Signed-off-by: onur-ozkan <[email protected]>
This is already handled at the config parsing level, so we can simplify it. Signed-off-by: onur-ozkan <[email protected]>
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
Co-authored-by: Oli Scherer <[email protected]>
Edit from rust-lang#126631 to revert changes on ui tests
…compatible lifetimes
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`
…, r=matthewjasper
match lowering: expand or-candidates mixed with candidates above
This PR tweaks match lowering of or-patterns. Consider this:
```rust
match (x, y) {
(1, true) => 1,
(2, false) => 2,
(1 | 2, true | false) => 3,
(3 | 4, true | false) => 4,
_ => 5,
}
```
One might hope that this can be compiled to a single `SwitchInt` on `x` followed by some boolean checks. Before this PR, we compile this to 3 `SwitchInt`s on `x`, because an arm that contains more than one or-pattern was compiled on its own. This PR groups branch `3` with the two branches above, getting us down to 2 `SwitchInt`s on `x`.
We can't in general expand or-patterns freely, because this interacts poorly with another optimization we do: or-pattern simplification. When an or-pattern doesn't involve bindings, we branch the success paths of all its alternatives to the same block. The drawback is that in a case like:
```rust
match (1, true) {
(1 | 2, false) => unreachable!(),
(2, _) => unreachable!(),
_ => {}
}
```
if we used a single `SwitchInt`, by the time we test `false` we don't know whether we came from the `1` case or the `2` case, so we don't know where to go if `false` doesn't match.
Hence the limitation: we can process or-pattern alternatives alongside candidates that precede it, but not candidates that follow it. (Unless the or-pattern is the only remaining match pair of its candidate, in which case we can process it alongside whatever).
This PR allows the processing of or-pattern alternatives alongside candidates that precede it. One benefit is that we now process or-patterns in a single place in `mod.rs`.
r? `@matthewjasper`
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
…by789 override user defined channel when using precompiled rustc We need to override `rust.channel` if it's manually specified when using the CI rustc. This is because if the compiler uses a different channel than the one specified in config.toml, tests may fail due to using a different channel than the one used by the compiler during tests. For more context, see rust-lang#122709 (comment).
…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.
…drop-glue, r=oli-obk Make async drop code more consistent with regular drop code Fixes rust-lang#126573 Relates to rust-lang#126482 r? ``@petrochenkov``
…-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-run-make
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Best of luck, you might need it! 😆 |
|
@bors r- |
bors
added
S-waiting-on-author
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:
bin-emit-no-symbolsrun-maketest tormake#125787 (Migratebin-emit-no-symbolsrun-maketest tormake)ArrayToPointerandMutToConstPointerfrom runtime MIR #126308 (BanArrayToPointerandMutToConstPointerfrom runtime MIR)rustc-ice*to.gitignore#126615 (Addrustc-ice*to.gitignore)move||withmove ||#126632 (Replacemove||withmove ||)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup