-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
move closure kind, signature into ClosureSubsts
#45879
move closure kind, signature into ClosureSubsts
#45879
Conversation
cc @Mark-Simulacrum -- potential breaking change |
src/librustc/infer/freshen.rs
Outdated
|substs| tcx.mk_closure(def_id, substs) | ||
) | ||
} | ||
|
||
ty::TyGenerator(def_id, substs, interior) => { |
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.
Don't you want to do this change for generators too? Generators referencing themselves are just as bad as closures doing so.
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.
Yes, but for purposes of getting crater results, not really needed. Will do, however.
Hmm, the mir-opt tests seem... maybe real? Will have to investigate later. |
The mir-opt problem turns out to be an existing bug in inlining. |
So should we do a crater run here? In that case, do we want to do a try build? |
☔ The latest upstream changes (presumably #45785) made this pull request unmergeable. Please resolve the merge conflicts. |
3a1134d
to
d5a54a9
Compare
cc @rust-lang/infra -- what is the procedure for doing a crater run here? |
@bors try |
[WIP] move closure kind, signature into `ClosureSubsts` Instead of using side-tables, store the closure-kind and signature in the substitutions themselves. This has two key effects: - It means that the closure's type changes as inference finds out more things, which is very nice. - As a result, it avoids the need for the `freshen_closure_like` code (though we still use it for generators). - It avoids cyclic closures calls. - These were never meant to be supported, precisely because they make a lot of the fancy inference that we do much more complicated. However, due to an oversight, it was previously possible -- if challenging -- to create a setup where a closure *directly* called itself (see e.g. #21410). We have to see what the effect of this change is, though. Needs a crater run. Marking as [WIP] until that has been assessed. r? @arielb1
☀️ Test successful - status-travis |
r? @arielb1 (assigning a reviewer) |
Rebased. |
d5a54a9
to
0f6bd17
Compare
I also decided to start an "old school" crater run.
Root regressions, sorted by rank:
|
@bors try |
[WIP] move closure kind, signature into `ClosureSubsts` Instead of using side-tables, store the closure-kind and signature in the substitutions themselves. This has two key effects: - It means that the closure's type changes as inference finds out more things, which is very nice. - As a result, it avoids the need for the `freshen_closure_like` code (though we still use it for generators). - It avoids cyclic closures calls. - These were never meant to be supported, precisely because they make a lot of the fancy inference that we do much more complicated. However, due to an oversight, it was previously possible -- if challenging -- to create a setup where a closure *directly* called itself (see e.g. #21410). We have to see what the effect of this change is, though. Needs a crater run. Marking as [WIP] until that has been assessed. r? @arielb1
☀️ Test successful - status-travis |
@nikomatsakis just pinging rust-lang/infra and saying "requesting crater run" will (eventually) get a crater run done. |
@aidanhs thanks =) |
So, based on the "old school" crater results (no regressions), I see three paths forward:
I'm leaning mildly towards path 2, but we'll see how much time I get for it. I just prefer to give warnings if we can. |
// not known to hold in the creator's context (and | ||
// indeed the closure may not be invoked by its | ||
// creator, but rather turned to someone who *can* | ||
// verify 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 also doesn't check captured variables from the parent function's generics.
Maybe these don't matter, because within a function the generics are always the function's own - and therefore WF, and outside of it a TyClosure
should not appear in the wild. So I'll either add the generics in, or be sure they don't matter and add a comment..
EntryKind::Generator(self.lazy(&data)) | ||
} | ||
|
||
ty::TyClosure(def_id, substs) => { |
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.
nit: isn't a closure's signature stored in the closure's item type? storing the data separately feels like it's only likely to cause mimsmatches and trouble (aka can't CrateMetadata::fn_sig
call tcx.item_type(def_id).closure_sig(def_id, tcx)
?)
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.
Does seem silly. Let me see if it can be readily purged.
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.
It's not really obvious to me how to do this. I'm sure it can be done, but I don't think that item_type
will do it. I believe that gives back something with "identity" substitutions, which isn't really what we want here (i.e., the closure_sig
parameter will be an unsubstituted type parameter). The other definition of fn_sig
uses the typeck_tables
to get what we want, but for that we need the HirId
of the closure, and I'm not sure how to get that from another crate.
r=me mod. comments also, apparently MIR inlining is still somewhat broken with closures. I'll try to open an issue.
|
this is #46086 |
36c7dc0
to
c490241
Compare
c490241
to
df6fdbc
Compare
Test problem:
|
r=me with test fixed. |
@bors r+ |
📌 Commit 9af5a06 has been approved by |
@bors r=arielb1 |
📌 Commit b9c766c has been approved by |
Before we were assuming that *every* `fn_sig` must pertain to a local closure.
@bors r=arielb1 |
📌 Commit 00732a3 has been approved by |
move closure kind, signature into `ClosureSubsts` Instead of using side-tables, store the closure-kind and signature in the substitutions themselves. This has two key effects: - It means that the closure's type changes as inference finds out more things, which is very nice. - As a result, it avoids the need for the `freshen_closure_like` code (though we still use it for generators). - It avoids cyclic closures calls. - These were never meant to be supported, precisely because they make a lot of the fancy inference that we do much more complicated. However, due to an oversight, it was previously possible -- if challenging -- to create a setup where a closure *directly* called itself (see e.g. #21410). We have to see what the effect of this change is, though. Needs a crater run. Marking as [WIP] until that has been assessed. r? @arielb1
☀️ Test successful - status-appveyor, status-travis |
Instead of using side-tables, store the closure-kind and signature in the substitutions themselves. This has two key effects:
freshen_closure_like
code (though we still use it for generators).We have to see what the effect of this change is, though. Needs a crater run. Marking as [WIP] until that has been assessed.
r? @arielb1