-
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
Handle type errors in closure/generator upvar_tys #78432
Conversation
Co-authored-by: Roxane Fruytier <roxane.fruytier@hotmail.com>
r? @oli-obk (rust_highfive has picked a reviewer for you, use r? to override) |
compiler/rustc_middle/Cargo.toml
Outdated
@@ -8,6 +8,7 @@ edition = "2018" | |||
doctest = false | |||
|
|||
[dependencies] | |||
either = "1.5.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a note, this is an extra dependency, don't know how willing we are to accept that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems pretty reasonable, but I have a suggestion to avoid the Either
dependency.
compiler/rustc_middle/src/ty/sty.rs
Outdated
#[inline] | ||
pub fn upvar_tys(self) -> impl Iterator<Item = Ty<'tcx>> + 'tcx { | ||
self.tupled_upvars_ty().tuple_fields() | ||
match self.tupled_upvars_ty().kind() { | ||
TyKind::Error(_) => Either::Left(std::iter::empty()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
May I suggest returning None
here...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
compiler/rustc_middle/src/ty/sty.rs
Outdated
self.tupled_upvars_ty().tuple_fields() | ||
match self.tupled_upvars_ty().kind() { | ||
TyKind::Error(_) => Either::Left(std::iter::empty()), | ||
TyKind::Tuple(..) => Either::Right(self.tupled_upvars_ty().tuple_fields()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...and Some(self.tupled_upvars_ty().tuple_fields())
here...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
TyKind::Tuple(..) => Either::Right(self.tupled_upvars_ty().tuple_fields()), | ||
TyKind::Infer(_) => bug!("upvar_tys called before capture types are inferred"), | ||
ty => bug!("Unexpected representation of upvar types tuple {:?}", ty), | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and then calling .into_iter().flatten()
here, then you can avoid the Either
dependency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
compiler/rustc_middle/src/ty/sty.rs
Outdated
#[inline] | ||
pub fn upvar_tys(self) -> impl Iterator<Item = Ty<'tcx>> + 'tcx { | ||
self.tupled_upvars_ty().tuple_fields() | ||
match self.tupled_upvars_ty().kind() { | ||
TyKind::Error(_) => Either::Left(std::iter::empty()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can get rid of the last Either as well
9760552
to
5229571
Compare
@bors r+ p=1 Giving p=1 because fixes a P-high regression. |
📌 Commit 5229571 has been approved by |
⌛ Testing commit 5229571 with merge 794cbe28f8b07229c3ad9a8e05849706276bc6c4... |
💔 Test failed - checks-actions |
@bors retry Unclear what causes this error, but it seems to be spurious. https://zulip-archive.rust-lang.org/242791tinfra/66128applex8664ghachecks.html |
⌛ Testing commit 5229571 with merge 9aa73f5280f6909336dcfba74e35c9000444c7d0... |
💔 Test failed - checks-actions |
@bors retry GitHub internal error :/ |
☀️ Test successful - checks-actions |
This seems to be a win on the match-stress benchmark -- up to 6% -- though this is relatively surprising, and it does not appear to be noise. Did we expect such an effect? A cursory look over the PR doesn't suggest an obvious reason, so maybe we missed something in the implementation? CPU cycles and wall times also improved. |
Somewhat surprising indeed. |
This was discussed briefly in compiler triage and settled as likely fine, though no particular explanations arose either. |
Fixes #77993