Conversation
|
Bear in mind, I've done these patches at the instruction of @eddyb and don't yet 100% understand what's going on with the substs here. Please direct complex questions to him :) |
|
I'm just betting/hoping that everything lines up correctly 😅. |
nikomatsakis
left a comment
There was a problem hiding this comment.
I left some comments. But in general I am confused about the "overall direction" of these changes -- they seem to be eliding type information when generating the clone impl, but don't we need that type information to know how big thing are and so forth? What am I missing?
src/librustc_mir/shim.rs
Outdated
There was a problem hiding this comment.
I..don't understand this. How can we have just one shim for all monomorphizations? Don't their sizes depend on the specific types in use?
There was a problem hiding this comment.
And what does this DefId refer to anyhow?
There was a problem hiding this comment.
Shims are not per-monomorphization, they're pretty generic (look at some of the other ones). CloneShim (and now the CloneStructuralShim) was incorrectly too monomorphic (but the array/tuple cases are harder to fix).
What's happening now is that there's only one MIR body forreturn *self; and one per closure definition, which you monomorphize just like you'd monomorphize a generic closure definition.
There was a problem hiding this comment.
"One shim for all monomorphizations" is the reason behind this PR. As for how it works, ask @eddyb
src/librustc/ty/instance.rs
Outdated
There was a problem hiding this comment.
Wait, pre-existing but... how .. does this work? name = tcx.type_of(def_id); if name == "clone"?? Isn't name a Ty<'tcx>?
There was a problem hiding this comment.
I guess that the travis failure answers that question (i.e., it doesn't work).
There was a problem hiding this comment.
lol I broke this in a rebase by accident. It used to be item_name
src/librustc/ty/instance.rs
Outdated
There was a problem hiding this comment.
Why is this not CloneClosureShim?
There was a problem hiding this comment.
And (in all cases) can you comment what the DefId refers to? (If you're feeling heroic, do the same for the other variants)
There was a problem hiding this comment.
It used to be CloneClosureShim and eddyb had me change it to use a more generic name 😄
There was a problem hiding this comment.
It's literally Clone::clone - all of the variants (have to) record the original DefId that was passed to Instance::resolve or something more specific (mostly for InstanceDef::Item.
src/librustc/ty/instance.rs
Outdated
There was a problem hiding this comment.
comment about what ty is the def-id of...
There was a problem hiding this comment.
The nominal type definition (closure, ADT, etc. - @Manishearth has a branch where enums also want this). Could use a better field name.
2b830b2 to
2c33d2f
Compare
|
Fails on run-pass/clone-closure.rs @eddyb any idea what's going on? |
|
@Manishearth You need a backtrace, I have no idea. |
|
|
If I make the closure not capture variables, I get |
|
I've kind of lost the thread here. What is the status? @Manishearth do you need guidance? |
Waiting to figure out what is going on =)
|
I haven't had the time to investigate the crash, but if you have a guess as to where it's coming from I'd love to know. |
|
@Manishearth friendly ping from (release team) triage :) What is the status of this PR? |
|
Still haven't had the time. |
|
It's PR triage time again, @Manishearth! How's it going? |
|
Nope. Feel free to close if you wish, but if someone else wants to take it over that works too (@eddyb ?) |
|
☔ The latest upstream changes (presumably #46882) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Closing for inactivity. @Manishearth, if you find the time to work on this again feel free to reopen this PR! |
r? @nikomatsakis
cc @eddyb