Link Vec leak doc to Box

[pickfire]

No description provided.

[rust-highfive]

r? @sfackler

(rust_highfive has picked a reviewer for you, use r? to override)

[jyn514]

r=me with CI passing

[pickfire]

This function is mainly useful for data that lives for the remainder of the program's life. Dropping the returned reference will cause a memory leak.

I still don't quite know how to prevent memory leak from reading the docs, I found this in the release notes.

[jyn514]

I think the right way to avoid a leak is Vec::from(Box::from_raw(ptr))? But I don't know how that interacts with fat pointers and raw slices.

cc @rust-lang/wg-unsafe-code-guidelines - how do you get a Vec back after you've leaked it?

[m-ou-se]

Turning the leak back into a Vec can be tricky and dangerous. If the leak() is 'static, anything could've copied that reference and access it at any point until the end of the program.

[RalfJung]

The docs do not even guarantee that into_boxed_slice is used, so in principle there could be extra capacity after the initialized part of the Vec -- which means restoring the original Vec actually is impossible as the capacity is lost.

If recovering from the leak is an intended feature, that would require a new guarantee currently not made by the docs.

[jyn514]

Got it, thanks. So I think we should document that this is not currently supported; right now it seems to imply there's a way if only you figure it out:

   /// This function is mainly useful for data that lives for the remainder of
    /// the program's life. Dropping the returned reference will cause a memory
    /// leak.

[pickfire]

Maybe we should mention that there is no way to recover the leak unlike box? Since for box it show some methods to recover the leak but I don't see that for vec, maybe it would be good to mention it to be explicit.

Sounds like a potential footgun, I feel like the function should be unsafe even though the word "leak" already feels scary enough.

[jyn514]

I feel like the function should be unsafe

#24456

[RalfJung]

To elaborate on what @jyn514 said: "footgun" is not what unsafe is about.

unsafe is about whether safe code can cause UB by calling this function in arbitrary ways. The answer here is "no", and thus it should not be unsafe.

[pickfire]

It can't cause UB but it can cause memory leak, so memory leak is safe? Yeah, I agree that causing UB is definitely unsafe but memory leak feels unsafe to me too.

[Mark-Simulacrum]

Memory leaking must be safe; we cannot prevent it: e.g., mem::forget is safe, see also the issue @jyn514 linked #24456.

[RalfJung]

UB for Rust is defined here. Memory leaks indeed are not on that list.

[pickfire]

Warning: The following list is not exhaustive. There is no formal model of Rust's semantics for what is and is not allowed in unsafe code, so there may be more behavior considered unsafe. The following list is just what we know for sure is undefined behavior. Please read the Rustonomicon before writing unsafe code.

Should we clarify that memory leak won't be part of that list?

[RalfJung]

Many things are not part of that list, listing them all could get exhausting. ;)
But anyway that is off-topic for this PR. Please open an issue for the reference if you want to continue this discussion.

For the PR, I agree the docs here should be clarified to say that there is no supported way to "undo the leak".

[jyn514]

r=me with nit fixed

[jyn514]

@bors r+ rollup

Thanks for the PR and starting a good discussion :)

[bors]

📌 Commit 8688fa8 has been approved by jyn514