Refactor how closures are represented to expose the types of the upvars #27087
Conversation
|
@arielb1 ordinary fn pointers are virtual dispatch |
yeah, probably, thanks. :) |
|
Using a dead type for a type parameter in that context does require virtual dispatch in the closure case too: if you can access the closure while it isn't hidden behind an object, you must be within the parent functions' scope, and its type parameters must therefore be alive. If/when fn items store their substs as part of their type, they will behave similarly (fn-items are unnameable in the same way as closures, so this interacts in the same way with anonymous types). |
|
r=me with the comments addressed |
|
☔ The latest upstream changes (presumably #27176) made this pull request unmergeable. Please resolve the merge conflicts. |
nikomatsakis
force-pushed
the
closure-exploration
branch
from
11f27b3 to
7a04326
Compare
TyClosure variant; thread this through wherever closure substitutions are expected, which leads to a net simplification. Simplify trans treatment of closures in particular.
This was the intention before but silly coding caused it to run twice if there are nested closures.
is being used now before the final regionck stage and in some cases SOME amount of unresolved inference is OK. In fact, we could probably just allow inference variables as well with only minimal pain.
upvars after analysis is done. Remove the `closure_upvars` helper and just consult this list of type variables directly.
…is now impossible.
nikomatsakis
force-pushed
the
closure-exploration
branch
2 times, most recently
from
138b551 to
71d4418
Compare
|
@bors r=nrc |
|
📌 Commit 71d4418 has been approved by |
|
@bors r=nrc |
|
📌 Commit 71d4418 has been approved by |
|
⌛ Testing commit 71d4418 with merge 5c3cc0c... |
|
💔 Test failed - auto-mac-32-opt |
|
@bors: retry On Fri, Jul 24, 2015 at 6:20 AM, bors notifications@github.com wrote:
|
Refactors the "desugaring" of closures to expose the types of the upvars. This is necessary to be faithful with how actual structs work. The reasoning of the particular desugaring that I chose is explained in a fairly detailed comment. As a side-effect, recursive closure types are prohibited unless a trait object intermediary is used. This fixes #25954 and also eliminates concerns about unrepresentable closure types that have infinite size, I believe. I don't believe this can cause regressions because of #25954. (As for motivation, besides #25954 etc, this work is also intended as refactoring in support of incremental compilation, since closures are one of the thornier cases encountered when attempting to split node-ids into item-ids and within-item-ids. The goal is to eliminate the "internal def-id" distinction in astdecoding. However, I have to do more work on trans to really make progress there.) r? @nrc
Refactors the "desugaring" of closures to expose the types of the upvars. This is necessary to be faithful with how actual structs work. The reasoning of the particular desugaring that I chose is explained in a fairly detailed comment.
As a side-effect, recursive closure types are prohibited unless a trait object intermediary is used. This fixes #25954 and also eliminates concerns about unrepresentable closure types that have infinite size, I believe. I don't believe this can cause regressions because of #25954.
(As for motivation, besides #25954 etc, this work is also intended as refactoring in support of incremental compilation, since closures are one of the thornier cases encountered when attempting to split node-ids into item-ids and within-item-ids. The goal is to eliminate the "internal def-id" distinction in astdecoding. However, I have to do more work on trans to really make progress there.)
r? @nrc