Should drop glue use #[track_caller]?

rustc nightly 2020-12-22 and stable 1.48.0

Playground link

struct Bomb;

impl Drop for Bomb {
    fn drop(&mut self) { panic!("bomb dropped!"); }

fn main() {
    Finished dev [unoptimized + debuginfo] target(s) in 1.15s
     Running `target/debug/playground`
thread 'main' panicked at 'bomb dropped!', /rustc/bb1fbbf84455fbad9afd26c17e0f725019322655/library/core/src/ptr/
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The location in this panic isn't very useful. (Ideally one would like to see a line in fn main). I wonder if core::ptr::drop_in_place should be annotated as #[track_caller]? Are there any downsides to this?

1 Like

Marking drop_in_place as #[track_caller] would have a severe negative impact on binary size and likely a non-neglectable decrease in runtime performance due to every implicit drop now having an &'static Location associated to it (huge size increase) that is passed to drop_in_place (increased register pressure)


In theory, since nearly all Drop::drop functions are not #[track_caller], that extra unused argument would be optimized out. But that's putting a lot on optimization and would at best have a noticable negative impact on compile time.

Given that drop bombs should never happen (and are often off in release mode) and are single use, what speaks against a more sophisticated drop bomb that always prints the stack and useful debug info when active?

1 Like