Hi, It looks like calls to `Drop::drop()` are getting removed when using `lto = "fat"` for a release build. It doesn't seem to occur with `lto = "thin"` or `lto = "no"`. I've got a test case here: https://github.com/cstorey/fat-lto-drop-repro, which can be reproduced like this: ``` : cez@ceri-no-mini; cargo --version; rustc --version; cargo run; cargo run --release cargo 1.37.0 (9edd08916 2019-08-02) rustc 1.37.0 (eae3437df 2019-08-13) Finished dev [unoptimized + debuginfo] target(s) in 0.00s Running `target/debug/lto-drop` About to panic thread 'main' panicked at '???', src/libcore/option.rs:1034:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. Dropping a Droppable Finished release [optimized] target(s) in 0.00s Running `target/release/lto-drop` About to panic thread 'main' panicked at '???', src/libcore/option.rs:1034:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. : cez@ceri-no-mini; ``` (more details in the [transcript](https://github.com/cstorey/fat-lto-drop-repro/blob/master/README.md)) For context, I first noticed this in a project where I am using an `mpsc::channel` to communciate between threads, where a producer thread reads messages from the network, and the main thread saves those to a database. I was relying on the fact that the `Drop` implementation for a channel will in effect close the channel, so the main thread can find out that the producer has failed, and so we should kill the process. What I saw instead was the producer thread panicing, but the main thread would never get woken up. I've seen this on macOS `Darwin 17.7.0 x86_64` and Linux `5.0.0-25-generic #26-Ubuntu SMP Thu Aug 1 12:04:58 UTC 2019 x86_64`.
