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

Use tuple inference for closures #23

Merged
merged 4 commits into from
Oct 15, 2020
Merged

Conversation

roxelo
Copy link
Member

@roxelo roxelo commented Sep 16, 2020

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 Reviewable

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(_)) {
Copy link
Member

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() {
Copy link
Member

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.
Copy link
Member

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.

@roxelo roxelo force-pushed the use_tuple_inference_for_closures branch from fd4c7e3 to 30ab719 Compare September 30, 2020 23:03
@@ -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.
Copy link
Member Author

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

@roxelo roxelo force-pushed the use_tuple_inference_for_closures branch from fe5b9c1 to 5648be6 Compare October 4, 2020 20:20
@arora-aman arora-aman force-pushed the use_tuple_inference_for_closures branch 3 times, most recently from aa27996 to 66d5d96 Compare October 7, 2020 07:52
@arora-aman arora-aman force-pushed the use_tuple_inference_for_closures branch 2 times, most recently from ee267c0 to 0bd6588 Compare October 11, 2020 07:25
roxelo and others added 3 commits October 11, 2020 03:32
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>
@arora-aman arora-aman force-pushed the use_tuple_inference_for_closures branch from 0bd6588 to 3c46fd6 Compare October 11, 2020 07:34
@sexxi-bot sexxi-bot merged commit 93deabc into master Oct 15, 2020
@arora-aman arora-aman deleted the use_tuple_inference_for_closures branch October 21, 2020 09:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Always make the "upvar types" a tuple of the actual upvar types (Parent issue#53488)
4 participants