-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 10 pull requests #126635
Rollup of 10 pull requests #126635
Conversation
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
…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
Signed-off-by: onur-ozkan <work@onurozkan.dev>
This is already handled at the config parsing level, so we can simplify it. Signed-off-by: onur-ozkan <work@onurozkan.dev>
Co-authored-by: Oli Scherer <github35764891676564198441@oli-obk.de>
Edit from rust-lang#126631 to revert changes on ui tests
…compatible lifetimes
…r-errors Test that opaque types can't have themselves as a hidden type with incompatible lifetimes fixes rust-lang#122876 This PR used to add extra logic to prevent those cases, but after rust-lang#113169 this is implicitly rejected, because such usages are not defining.
…field, r=jackh726 Suggest removing unused tuple fields if they are the last fields Fixes rust-lang#124556 We now check if dead/unused fields are the last fields of the tuple and suggest their removal instead of suggesting them to be changed to `()`.
…trait, r=compiler-errors improve tip for inaccessible traits Improve the tips when the candidate method is from an inaccessible trait. For example: ```rs mod m { trait Trait { fn f() {} } impl<T> Trait for T {} } fn main() { struct S; S::f(); } ``` The difference between before and now is: ```diff error[E0599]: no function or associated item named `f` found for struct `S` in the current scope --> ./src/main.rs:88:6 | LL | struct S; | -------- function or associated item `f` not found for this struct LL | S::f(); | ^ function or associated item not found in `S` | = help: items from traits can only be used if the trait is implemented and in scope - help: trait `Trait` which provides `f` is implemented but not in scope; perhaps you want to import it + help: trait `crate::m::Trait` which provides `f` is implemented but not reachable | - LL + use crate::m::Trait; | ```
Rewrite `intrinsic-unreachable`, `sepcomp-cci-copies`, `sepcomp-inlining` and `sepcomp-separate` `run-make` tests to rmake.rs Part of rust-lang#121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
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`
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).
…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.
@bors r+ p=5 rollup=never |
🔒 Merge conflict This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again. How do I rebase?Assuming
You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial. Please avoid the "Resolve conflicts" button on GitHub. It uses Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Error message
|
☔ The latest upstream changes (presumably #126623) made this pull request unmergeable. Please resolve the merge conflicts. |
Successful merges:
intrinsic-unreachable
,sepcomp-cci-copies
,sepcomp-inlining
andsepcomp-separate
run-make
tests to rmake.rs #126427 (Rewriteintrinsic-unreachable
,sepcomp-cci-copies
,sepcomp-inlining
andsepcomp-separate
run-make
tests to rmake.rs)rustc-ice*
to.gitignore
#126615 (Addrustc-ice*
to.gitignore
)move||
withmove ||
#126632 (Replacemove||
withmove ||
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup