don't report memory leaks for static data

[matklad]

Currently, miri reports a memory leak for a static with heap allocated data. This is somewhat expected, as statics don't run destructors and indeed leak memory. However, this is not error, and ideally shouldn't be reported by miri as such.

See matklad/once_cell@327f4e2 for an example.

[oli-obk]

Oh, heh. I never thought about heap pointers being leaked into statics. Also calls to Box::leak should probably not trigger the leak errors.

Maybe we should, before running the check, recursively mark anything reachable by a static as static itself.

And we should add a hook to Box::leak to make it mark its memory as static (we can use rustc_diagnostic_item to get the DefId of Box::leak

[RalfJung]

We probably also should make the leak check optional. A quick solution would be -Zmiri-allow-leaks; or we could make the leak error a "deny-by-default lint" and then use -Aleak or so.

And we should add a hook to Box::leak to make it mark its memory as static

Why that? I think our leak check should trigger for Box::leak memory that is actually leaked.

[oli-obk]

Why that? I think our leak check should trigger for Box::leak memory that is actually leaked.

I assumed that Box::leak could never be undone, but even stacked borrows is fine with it: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=cae54e950dfd613b3c255263f352795f

I'm assuming &'static mut T and *mut T are equal in the eyes of stacked borrows

My statement came from assuming that people don't use Box::leak and expect to ever take back ownership of that. If you ever stored it in a global it seems impossible to ever safely undo the leak because any other code may have an immutable reference to the thing.

Nixing the entire leak check, just because some code found it ok to leak a single value out of lazy static like reasons, seems a bit extreme.

[RalfJung]

I'm assuming &'static mut T and *mut T are equal in the eyes of stacked borrows

No they are not (the former disallows accesses through other aliases).

My statement came from assuming that people don't use Box::leak and expect to ever take back ownership of that. If you ever stored it in a global it seems impossible to ever safely undo the leak because any other code may have an immutable reference to the thing.

I see. It would seem odd though, I think, to enshrine this in the operational semantics.

Nixing the entire leak check, just because some code found it ok to leak a single value out of lazy static like reasons, seems a bit extreme.

We could also have a magic crazy intrinsic "tell Miri this here is allowed to leak"... I think I will regret suggesting this, though. ;)

[RalfJung]

I just ran into another instance of this. The following program is considered leaking:

fn main() {
    let _val = 0;
    // Capture something to make closure a non-ZST
    std::panic::set_hook(Box::new(move |_info| { _val; }));
}

[RalfJung]

On Windows, we need this even to get an empty fn main() {} working with the leak checker enabled: there are some statics in libstd that are otherwise considered leaking.