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

Handle match statements with non exhaustive variants in closures #88280

Merged
merged 4 commits into from
Aug 29, 2021

Conversation

roxelo
Copy link
Member

@roxelo roxelo commented Aug 24, 2021

This PR ensures that the behavior for match statements with non exhaustive variants is the same inside and outside closures.

If we have a non-exhaustive SingleVariant which is defined in a different crate, then we should handle the case the same way we would handle a MultiVariant: borrow the match discriminant.

Closes rust-lang/project-rfc-2229#59
r? @nikomatsakis

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 24, 2021
Copy link
Contributor

@nikomatsakis nikomatsakis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great! 🎉

@nikomatsakis
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Aug 24, 2021

📌 Commit 68b1bfc has been approved by nikomatsakis

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 24, 2021
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Aug 26, 2021
…atsakis

Handle match statements with non exhaustive variants in closures

This PR ensures that the behavior for match statements with non exhaustive variants is the same inside and outside closures.

If we have a non-exhaustive SingleVariant which is defined in a different crate, then we should handle the case the same way we would handle a MultiVariant: borrow the match discriminant.

Closes rust-lang/project-rfc-2229#59
r? `@nikomatsakis`
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Aug 26, 2021
…atsakis

Handle match statements with non exhaustive variants in closures

This PR ensures that the behavior for match statements with non exhaustive variants is the same inside and outside closures.

If we have a non-exhaustive SingleVariant which is defined in a different crate, then we should handle the case the same way we would handle a MultiVariant: borrow the match discriminant.

Closes rust-lang/project-rfc-2229#59
r? ``@nikomatsakis``
Manishearth added a commit to Manishearth/rust that referenced this pull request Aug 27, 2021
…atsakis

Handle match statements with non exhaustive variants in closures

This PR ensures that the behavior for match statements with non exhaustive variants is the same inside and outside closures.

If we have a non-exhaustive SingleVariant which is defined in a different crate, then we should handle the case the same way we would handle a MultiVariant: borrow the match discriminant.

Closes rust-lang/project-rfc-2229#59
r? ```@nikomatsakis```
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Aug 27, 2021
…atsakis

Handle match statements with non exhaustive variants in closures

This PR ensures that the behavior for match statements with non exhaustive variants is the same inside and outside closures.

If we have a non-exhaustive SingleVariant which is defined in a different crate, then we should handle the case the same way we would handle a MultiVariant: borrow the match discriminant.

Closes rust-lang/project-rfc-2229#59
r? ````@nikomatsakis````
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Aug 27, 2021
…atsakis

Handle match statements with non exhaustive variants in closures

This PR ensures that the behavior for match statements with non exhaustive variants is the same inside and outside closures.

If we have a non-exhaustive SingleVariant which is defined in a different crate, then we should handle the case the same way we would handle a MultiVariant: borrow the match discriminant.

Closes rust-lang/project-rfc-2229#59
r? `````@nikomatsakis`````
@bors
Copy link
Contributor

bors commented Aug 28, 2021

☔ The latest upstream changes (presumably #88390) made this pull request unmergeable. Please resolve the merge conflicts.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Aug 28, 2021
@ehuss
Copy link
Contributor

ehuss commented Aug 29, 2021

@bors r=nikomatsakis p=1

@bors
Copy link
Contributor

bors commented Aug 29, 2021

📌 Commit 33817d2 has been approved by nikomatsakis

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 29, 2021
@bors
Copy link
Contributor

bors commented Aug 29, 2021

⌛ Testing commit 33817d2 with merge 2f662b1...

@bors
Copy link
Contributor

bors commented Aug 29, 2021

☀️ Test successful - checks-actions
Approved by: nikomatsakis
Pushing 2f662b1 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 29, 2021
@bors bors merged commit 2f662b1 into rust-lang:master Aug 29, 2021
@rustbot rustbot added this to the 1.56.0 milestone Aug 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. 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.

Handle nonexhaustive in match pattern
6 participants