-
Notifications
You must be signed in to change notification settings - Fork 13k
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 6 pull requests #91093
Rollup of 6 pull requests #91093
Conversation
While it's an internal function, it is easy to create invalid Arc/Rcs to a dangling pointer with it. Fixes rust-lang#89740
Helps avoid rightward drift.
Because the parser directory has already reached the 1000 file limit.
Co-authored-by: Esteban Kuber <[email protected]>
…value" This reverts commit 0a2b7d7, reversing changes made to 47c1bd1. This caused several unforeseen problems: - rust-lang#91029 - rust-lang#89764 (comment)
…=Mark-Simulacrum Mark `Arc::from_inner` / `Rc::from_inner` as unsafe While it's an internal function, it is easy to create invalid Arc/Rcs to a dangling pointer with it. Fixes rust-lang#89740
…h726 Fix float ICE This fixes rust-lang#90728
Fix ICE `rust-lang#90993`: add missing call to cancel Fix rust-lang#90993
Adopt let_else in more places in rustc_mir_build Helps avoid rightward drift. followup of rust-lang#89933
…ebank Suggest `await` in more situations where infer types are involved Currently we use `TyS::same_type` in diagnostics that suggest adding `.await` to opaque future types. This change makes the suggestion slightly more general, when we're comparing types like `Result<T, E>` and `Result<_, _>` which happens sometimes in places like `match` patterns or `let` statements with partially-elaborated types. ---- Question: 1. Is this change worthwhile? Totally fine if it doesn't make sense adding. 2. Should `same_type_modulo_infer` live in `rustc_infer::infer::error_reporting` or alongside the other method in `rustc_middle::ty::util`? 3. Should we generalize this change? I wanted to change all usages, but I don't want erroneous suggestions when adding `.field_name`...
Revert "require full validity when determining the discriminant of a value" This reverts commit 0a2b7d7, reversing changes made to 47c1bd1. This caused several unforeseen problems: - rust-lang#91029 - rust-lang#89764 (comment) So I think it's best to revert for now while we keep discussing the MIR semantics of getting a discriminant. r? `@oli-obk`
@bors r+ rollup=never p=6 |
📌 Commit 83c83d4 has been approved by |
☀️ Test successful - checks-actions |
Tested on commit rust-lang/rust@5bc9807. Direct link to PR: <rust-lang/rust#91093> 🎉 miri on windows: test-fail → test-pass (cc @RalfJung @eddyb @oli-obk). 🎉 miri on linux: test-fail → test-pass (cc @RalfJung @eddyb @oli-obk).
Finished benchmarking commit (5bc9807): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Successful merges:
Arc::from_inner
/Rc::from_inner
as unsafe #89741 (MarkArc::from_inner
/Rc::from_inner
as unsafe)#90993
: add missing call to cancel #90994 (Fix ICE#90993
: add missing call to cancel)await
in more situations where infer types are involved #91022 (Suggestawait
in more situations where infer types are involved)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup