Throwing a panic via core::panic reports memory leak

[RalfJung]

When a #[should_panic] test throws via core::panic! instead of (the default) std::panic!, we have a memory leak:

Alloc 23790: 00 00 00 00 00 00 00 00 0d 00 00 00 00 00 00 00 35 00 00 00 05 00 00 00 (24 bytes, alignment 8) (stack)
             └───────(23789)───────┘ 
Alloc 23789: 74 65 73 74 73 2f 74 65 73 74 2e 72 73 (13 bytes, alignment 1) (Static)

The 2nd allocation is the string tests/test.rs and 0x35 is 53, the line with the panic statement; this looks like some kind of panic information struct.

The interesting question is, why does a stack allocation not get freed?

Cc @Aaron1011

[RalfJung]

This can easily be reproduced by adjusting our catch_panic test to use core::panic!.

[RalfJung]

#1073 contains some commented-out tests for this.

[oli-obk]

If we create a stack allocation without putting it into a frame's locals list, it will get leaked

[RalfJung]

The offending allocation is created here:

https://github.com/rust-lang/rust/blob/4752c05af4a5f392de026f9ae1877eae030be359/src/librustc_mir/interpret/intrinsics/caller_location.rs#L31

[bjorn3]

That should be treated like a const, right?

[RalfJung]

Not sure what you mean? Ideally it should probably be interned but I am not sure what the best way is to achieve that.

[bjorn3]

I mean it should be treated like const LOC_AT_THIS_POS: &'static Location = ....

[RalfJung]

Yeah that would be achieved by interning the result.

I went with rust-lang/rust#66844 instead as that seemed simpler; I was not sure how to best achieve interning here.