instance: polymorphize upvar closures/generators #75255
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rust-highfive
added
the
S-waiting-on-review
lcnr
reviewed
Aug 7, 2020
lcnr
reviewed
Aug 7, 2020
lcnr
reviewed
Aug 7, 2020
davidtwco
force-pushed
the
polymorphisation-symbol-mangling-v0-upvar-closures
branch
from
a6535d2
to
c6f361b
Compare
lcnr
approved these changes
Aug 7, 2020
There was a problem hiding this comment.
We may want to add a type flag like MAY_POLYMORPHIZE which checks if the ty is or contains a Closure or Generator so we don't have to always looking into the subst.
But apart from that this looks good to me, I don't think @eddyb also needs to look over this 🤔
r=me
|
I've addressed those comments, including adding the type flag. r? @lcnr |
lcnr
reviewed
Aug 7, 2020
lcnr
approved these changes
Aug 7, 2020
This commit modifies how instances are polymorphized so that closures and generators have any closures or generators captured within their upvars also polymorphized - this avoids symbol clashes with the new symbol mangling scheme. Signed-off-by: David Wood <david@davidtw.co>
By always polymorphizing substitutions, functions which take closures as arguments (e.g. `impl Fn()`) can have fewer mono items when some of the argument closures can be polymorphized. Signed-off-by: David Wood <david@davidtw.co>
This commit adds a `MAY_POLYMORPHIZE` which checks for closures and generators so that polymorphization of substs does not need to traverse every substs. Signed-off-by: David Wood <david@davidtw.co>
This commit avoids unnecessary calls to `mk_closure` and `mk_generator` by checking if the polymorphized substs match the original substs. Signed-off-by: David Wood <david@davidtw.co>
This commit extends previous polymorphization of substs to polymorphize `FnDef`. Signed-off-by: David Wood <david@davidtw.co>
davidtwco
force-pushed
the
polymorphisation-symbol-mangling-v0-upvar-closures
branch
from
e9cab0c
to
ac50d61
Compare
|
@bors r=lcnr |
|
📌 Commit ac50d61 has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions, checks-azure |
davidtwco
deleted the
polymorphisation-symbol-mangling-v0-upvar-closures
branch
davidtwco
added a commit
to davidtwco/rust
that referenced
this pull request
Aug 9, 2020
This commit restricts the substitution polymorphization added in rust-lang#75255 to only apply to the tupled upvar substitution, rather than all substitutions, fixing a bunch of regressions when polymorphization is enabled. Signed-off-by: David Wood <david@davidtw.co>
This was referenced Aug 9, 2020
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this pull request
Aug 10, 2020
…xes, r=eddyb instance: only polymorphize upvar substs This PR restricts the substitution polymorphization added in rust-lang#75255 to only apply to the tupled upvar substitution, rather than all substitutions, fixing a bunch of regressions when polymorphization is enabled. Due to an oversight on my part, when landing rust-lang#75260 and rust-lang#75255, some tests started failing when polymorphization was enabled that I didn't notice until after landing - this PR fixes the regressions from rust-lang#75255. rust-lang#75336 has been filed to make sure that we don't forget to try make this change again in future, as it does enable some optimisations. r? @lcnr
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this pull request
Aug 11, 2020
…xes, r=lcnr polymorphize: constrain unevaluated const handling This PR constrains the support added for handling unevaluated consts in polymorphization (introduced in rust-lang#75260) by: - Skipping associated constants as this causes cycle errors. - Skipping promoted constants when they contain `Self` as this ensures `T` is used in constants of the form `<Self as Foo<T>>`. Due to an oversight on my part, when landing rust-lang#75260 and rust-lang#75255, some tests started failing when polymorphization was enabled that I didn't notice until after landing - this PR fixes the regressions from rust-lang#75260. r? @lcnr
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR modifies how instances are polymorphized so that closures and generators have any closures or generators captured within their upvars also polymorphized.
With the new symbol mangling, a fully polymorphised closure will produce the same symbol regardless of what it was instantiated with. However, when that polymorphised closure captures another closure as an upvar, then the type of that other closure in the upvar substitution wouldn't have been polymorphised. The other closure will still refer to the initial substitutions. Therefore, the polymorphised closure will end up hashing differently but producing the same symbol - triggering
assert_symbols_are_distinctin MIR partitioning. The old mangling scheme had a hash at the end that meant this didn't happen (this would still have been an issue, we just didn't have a way to notice).See this Zulip discussion for further elaboration.
r? @eddyb
cc @lcnr