diff options
| author | Hrvoje Niksic <hniksic@gmail.com> | 2020-03-01 21:31:08 +0100 |
|---|---|---|
| committer | Hrvoje Niksic <hniksic@gmail.com> | 2020-03-19 14:48:48 +0100 |
| commit | 8e0398c060ba50bde4fe47a3685c0857285001bd (patch) | |
| tree | db7ba4ff2d66135bb5ebd5006b27dac98ea90deb /src/test/ui/thinlto | |
| parent | 3c6f982cc908aacc39c3ac97f31c989f81cc213c (diff) | |
| download | rust-8e0398c060ba50bde4fe47a3685c0857285001bd.tar.gz rust-8e0398c060ba50bde4fe47a3685c0857285001bd.zip | |
Clarify the relationship between `forget()` and `ManuallyDrop`.
As discussed on reddit, this commit addresses two issues with the documentation of `mem::forget()`: * The documentation of `mem::forget()` can confuse the reader because of the discrepancy between usage examples that show correct usage and the accompanying text which speaks of the possibility of double-free. The text that says "if the panic occurs before `mem::forget` was called" refers to a variant of the second example that was never shown, modified to use `mem::forget` instead of `ManuallyDrop`. Ideally the documentation should show both variants, so it's clear what it's talking about. Also, the double free could be fixed just by placing `mem::forget(v)` before the construction of `s`. Since the lifetimes of `s` and `v` wouldn't overlap, there would be no point where panic could cause a double free. This could be mentioned, and contrasted against the more robust fix of using `ManuallyDrop`. * This sentence seems unjustified: "For some types, operations such as passing ownership (to a funcion like `mem::forget`) requires them to actually be fully owned right now [...]". Unlike C++, Rust has no move constructors, its moves are (possibly elided) bitwise copies. Even if you pass an invalid object to `mem::forget`, no harm should come to pass because `mem::forget` consumes the object and exists solely to prevent drop, so there no one left to observe the invalid state state.
Diffstat (limited to 'src/test/ui/thinlto')
0 files changed, 0 insertions, 0 deletions
