user_fn frame and the
Memory need to be serialized and restored. Currently @Alexander Regueiro has implemented a manual scheme, and iirc wanted to check again why
RustcDeserialize aren't used instead
So, I believe I experimented with this some time ago (you may have suggested this formerly), and basically the issue was that a) it pulled in memory from the start fn and main's params
dead_alloc_map isn't something that we really want to serialise, I think
you need the
dead_alloc_map for a few operations. If it's not there you may run into trouble when doing things to dangling pointers
and trust me, users will do evil things with a REPL :D
about the wasted memory. Essentially the way you serialize is to serialize the frame of the closure, write down all alloc ids, serialize the corresponding
Alloations for the alloc ids, again writing down all new alloc ids encountered?
hmm I see
I will look into this for sure
I don't think it affects the first couple of PRs
RustcSeriaze/Deserialize implementation for
Memory should not be too hard. I'm sure I implemented it before and reverted it.
will do a bit more experimentation before opening the MIR PR, of course
I think you're right in that a manual deserialization works better, because it can skip everything that is not needed
But yea, you'll have to also preserve the dead alloc map entries that are reachable
okay, so I think we're in agreement there. I'll just make sure the dead alloc map gets serialised now! (I guess my simple test cases didn't catch problems with that, but indeed, someone would find a way to break it heh...)
Should the stacked borrow state be serialized too?
what exactly do you mean @bjorn3 ?
Stacked borrows is kind of a runtime version of the borrowchecker. To make it work correctly, it's state should be serialized too.
oh sorry, I parsed your sentence invalidly.
it currently is serialised for the miri backend, in fact.
it's "just" a dynamic correctness check though, as far as I'm aware? so it's not necessary for the Codegen backend.
indeed, cg_llvm doesn't implement it either. it requires a lot of dynamic instrumentation (every call and every borrow/deref) to implement it.
yep, I think this is fine. :-)
easy enough to say "if you want this sort of dynamic correctness checking, just use the miri backend".
yeah, it doesn't make much sense without the other UB checks anyway