Rollup merge of rust-lang#32383 - aidanhs:aphs-heap-move-guarantee, r…

…=alexcrichton

Document heap allocation location guarantee

```
14:25 < aidanhs> is there any guarantee that boxes will not move the value on the heap when they are moved?
14:26 <@steveklabnik> aidanhs: ... i'm not sure if it's a guarantee, but it follows, generally
14:26 <@steveklabnik> aidanhs: moves mean memcpy, so you're memcpying the structure of the box itself, which is copying the pointer
14:26 <@steveklabnik> so the pointer won't be updated
14:26 <@steveklabnik> moves cannot do complex things like move the memory around on the heap
14:26 <@kmc> aidanhs: I would say it's guaranteed
14:27 < aidanhs> steveklabnik: yeah, that's what I was thinking, it'd be pretty strange for rust to do something, but I couldn't find any docs one way or the other
14:27 <@steveklabnik> kmc: aidanhs yeah, it's like a borderline thing that we don't explicitly guanratee but i think IS guaranteed by our other guarantees
14:27 <@steveklabnik> mostly that move == memcpy
14:28 < aidanhs> kmc: steveklabnik great thanks! would a PR to the rust reference along these lines be ok?
14:28 < jmesmon> aidanhs: I believe owning_ref has some discussion of that (stable references)
14:29 <@steveklabnik> aidanhs: i would probably take that, yeah
14:29 < aidanhs> jmesmon: thanks, I'll take a look at that
```
https://botbot.me/mozilla/rust/2016-02-22/?msg=60657619&page=18

r? @steveklabnik

src/doc/reference.md

@@ -3911,6 +3911,9 @@ The _heap_ is a general term that describes boxes.  The lifetime of an
 allocation in the heap depends on the lifetime of the box values pointing to
 it. Since box values may themselves be passed in and out of frames, or stored
 in the heap, heap allocations may outlive the frame they are allocated within.
+An allocation in the heap is guaranteed to reside at a single location in the
+heap for the whole lifetime of the allocation - it will never be relocated as
+a result of moving a box value.
 
 ### Memory ownership