Skip to content
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 4 pull requests #91090

Closed
wants to merge 9 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

sdroege and others added 9 commits October 10, 2021 21:13
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.
…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
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`
@rustbot rustbot added the rollup A PR which is a rollup label Nov 20, 2021
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=4

@bors
Copy link
Contributor

bors commented Nov 20, 2021

📌 Commit 34615eb has been approved by matthiaskrgr

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Nov 20, 2021
@matthiaskrgr matthiaskrgr deleted the rollup-pq67ylv branch November 25, 2021 19:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants