-
Notifications
You must be signed in to change notification settings - Fork 0
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
Use tuple inference for closures #23
Conversation
for upvar_ty in substs.as_closure().upvar_tys() { | ||
compute_components(tcx, upvar_ty, out); | ||
let tupled_ty = substs.as_closure().tupled_upvars_ty(); | ||
if matches!(tupled_ty.kind(), ty::Tuple(_)) { |
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 is my bad, this can just be substs.as_closure().is_valid()
@@ -110,7 +110,12 @@ pub fn trivial_dropck_outlives<'tcx>(tcx: TyCtxt<'tcx>, ty: Ty<'tcx>) -> bool { | |||
// check if *any* of those are trivial. | |||
ty::Tuple(ref tys) => tys.iter().all(|t| trivial_dropck_outlives(tcx, t.expect_ty())), | |||
ty::Closure(_, ref substs) => { | |||
substs.as_closure().upvar_tys().all(|t| trivial_dropck_outlives(tcx, t)) | |||
if !substs.as_closure().is_valid() { |
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 can just be trivial_dropck_outlives(tcx, substs.as_closure().tupled_upvar_tys())
}) | ||
})); | ||
let tupled_upvars_ty = self.infcx.next_ty_var(TypeVariableOrigin { | ||
// FIXME(eddyb) distinguish upvar inference variables from the rest. |
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 feel like this isn't valid anymore, individual inference variable for each upvar, isn't a thing anymore.
fd4c7e3
to
30ab719
Compare
@@ -1307,6 +1307,26 @@ impl<'a, 'tcx> InferCtxtExt<'tcx> for InferCtxt<'a, 'tcx> { | |||
let mut generator = None; | |||
let mut outer_generator = None; | |||
let mut next_code = Some(&obligation.cause.code); | |||
// By introducing a tuple into the upvar types, the first item in the obligation chain | |||
// can be of Tuple type instead of the generator that captured the type. We want to catch for | |||
// this case and skip it. |
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 does the trick for now, but it's probably not what we want to move forward with. The tuple of upvar type should not be the first item in the obligation chain, probably more in the middle. We probably want to change how the obligation chain is created. I haven't figured out where in the code that is done yet though
fe5b9c1
to
5648be6
Compare
aa27996
to
66d5d96
Compare
ee267c0
to
0bd6588
Compare
This commit allows us to decide the number of captures required after completing capture ananysis, which is required as part of implementing RFC-2229. Co-authored-by: Aman Arora <me@aman-arora.com> Co-authored-by: Jenny Wills <wills.jenniferg@gmail.com>
Depending on if upvar_tys inferred or not, we were returning either an inference variable which later resolves to a tuple or else the upvar tys themselves Co-authored-by: Roxane Fruytier <roxane.fruytier@hotmail.com>
Co-authored-by: Roxane Fruytier <roxane.fruytier@hotmail.com>
0bd6588
to
3c46fd6
Compare
The main motivation behind this change is to allow the compiler to decide the number of captures after capture analysis instead of before capture analysis. T
This is required to support RFC-2229, since the number of captures will not be know before capture analysis.
Closes rust-lang/project-rfc-2229#4
This change is