Uh oh!
There was an error while loading. Please reload this page.
Cleanup the shim code - #47865
Conversation
d658161 to
973881dCompareManishearth
commented
Jan 30, 2018
973881d to
5bacd19CompareThere was a problem hiding this comment.
The confusion was "is it 0-indexed variant index, 1-indexed variant index, or the discriminant value". Basically, the fact that it says that it's zero for structs and unions suggests that it's perhaps nonzero for enums, and it's better if folks don't need to verify this.
There was a problem hiding this comment.
You can just edit that part instead of adding more elsewhere... also you wrote AdtDef::fields instead of variants. And this shouldn't be in this PR anyway.
There was a problem hiding this comment.
Actually structs and unions have exactly one variant so the rephrasing can be even more enum-focused.
Manishearth
commented
Jan 30, 2018
fixed |
5bacd19 to
510b3d2CompareThere was a problem hiding this comment.
The newline seems misplaced. Also, we should avoid using "discriminant", because that's a different thing that may not be equal to the variant index. All the relevant code uses "variant index" (not "variant number").
There was a problem hiding this comment.
Please put this before rcvr_field and rename that to src.
510b3d2 to
5602a2dCompareThere was a problem hiding this comment.
Please pass in ret_field from below as the destination (and rename it to dest_elem - also rcvr_field should be src_elem).
07b8813 to
92b533aCompareThere was a problem hiding this comment.
Please make this function also write in-place.
There was a problem hiding this comment.
Can you name this dest_field and put it before src_field?
There was a problem hiding this comment.
This should be named src not rcvr.
9dbce3f to
fbb26eeCompareManishearth
commented
Jan 30, 2018
done |
There was a problem hiding this comment.
This should be named previous_field, I think.
b113fed to
370315dCompare370315d to
f48eba7Compareeddyb
commented
Jan 30, 2018
cc @arielb1 |
dcb07dd to
ca17162Comparec94151b to
633e401Compare
nikomatsakis
left a comment
There was a problem hiding this comment.
Seems pretty good to me. A few nits/questions.
There was a problem hiding this comment.
is there a test for whatever motivated this commit?
There was a problem hiding this comment.
Without this commit everything ICEs. Everything.
Any code instantiating a clone shim of tuples or arrays or closures (libcore does) will break because the type used will be TySelf (not TyArray or TyClosure or whatever) and we'll get errors because we're trying to call .index() or .field() on a place that can't be indexed. I can leave a comment to this effect somewhere.
There was a problem hiding this comment.
I mean I can see why this is wrong, but I'm a bit confused -- the code works now, afaik, right? Or is this just patching up some earlier commit of yours?
There was a problem hiding this comment.
It breaks once the change to the array shim is made - anything that depends on the type (e.g. indexing or enum discriminants) starts breaking because it'd see an unsubstituted Self.
There was a problem hiding this comment.
Thsi commit should be earlier in the series I think.
We basically don't hit it because we write to temporary Places and then copy and that works well. I don't recall the exact details, but eddyb can explain.
There was a problem hiding this comment.
Oh right yeah this doesn't break the tuple stuff but it does break the array stuff (and the enum stuff from my other PR)
There was a problem hiding this comment.
Nit: can we use rustfmt-style formatting here?
There was a problem hiding this comment.
Hmm, I think this is ok, but it's interesting that we can observe the mutations even on unwind etc. Do you know off hand @eddyb if this is already true? Seems like something that we will eventually want to be legal, though. Effectively you're giving in an &mut to the (uninitialized) RETURN_PLACE, so we can do what we want there.
There was a problem hiding this comment.
But I feel like this has been an interesting question at times in the UCG discussions (when precisely can we reuse places etc).
Otherwise we get random TySelfs there, which means operations on RETURN_PLACE end up breaking down badly.
Manishearth
commented
Feb 1, 2018
done |
633e401 to
8a8f91bComparenikomatsakis
commented
Feb 1, 2018
@bors r+ |
bors
commented
Feb 1, 2018
📌 Commit 8a8f91b has been approved by |
bors
commented
Feb 5, 2018
Cleanup the shim code - We now write directly to `RETURN_PLACE` instead of creating intermediates - `tuple_like_shim` takes an iterator (used by #47867) - `tuple_like_shim` no longer relies on it being the first thing to create blocks, and uses relative block indexing in a cleaner way (necessary for #47867) - All the shim builders take `dest, src` arguments instead of hardcoding RETURN_PLACE r? @eddyb
bors
commented
Feb 5, 2018
☀️ Test successful - status-appveyor, status-travis |
RETURN_PLACEinstead of creating intermediatestuple_like_shimtakes an iterator (used by [WIP] Make derive(Clone) memcpy on enum variants containing only Copy types #47867)tuple_like_shimno longer relies on it being the first thing to create blocks, and uses relative block indexing in a cleaner way (necessary for [WIP] Make derive(Clone) memcpy on enum variants containing only Copy types #47867)dest, srcarguments instead of hardcoding RETURN_PLACEr? @eddyb