-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Circumvent type-instability of deepcopy #13323
Conversation
Hmmm, more complicated than I thought. I guess the fix for this depends on what deepcopy really means. Ref #13124. |
I don't really understand why that issue is related? |
The part about equivalence to "serialize" and "deserialize"---that's one way of stating a principle-of-operation for |
i think there's a related issue (noted in the serialization code), which is that if the exact type isn't returned, then it might get assigned to a field of a different type causing issues. i think we should either merge this, or perhaps insert the following slow path to deserialize and deepcopy: if typeof(elt) != fieldtype(T, i)
elt = convert(fieldtype(T, i), elt)
end |
I also think we should merge this. Unless I'm missing something, I don't think there is a need for deepcopy to literally give the same result as deserialize. That's just one way to understand the sort of thing it does. |
Hmm, the AppVeyor failure seems odd because one can see the final "SUCCESS", but then it's judged as failing. Anything to worry about here? |
try restarting? it looks all of the tests finished, but one of the subprocesses failed to shutdown |
👍 |
Due to the use of the
ObjectIdDict
,deepcopy
is type-unstable. Obviously this dict is important for avoiding cycles, so it seems the best solution is to prevent the type-instability from propagating.Ref JuliaImages/Images.jl#356