Drop glue is always inlined into caller crate

[alexcrichton]

I was investigating the compile time of a crate recently and came across a surprising aspect of the compiler. It looks like the drop glue, or rather the code necessary to drop a type, is inlined unconditionally into the caller crate, even if there are no generics in play.

This program:

pub fn a(_: std::process::Command) {}

generates a whopping 15 thousand lines of LLVM IR. Now Command certainly is a large type and I think it's fine that its drop glue is that big, but this is a concrete type and every single crate which uses Command is generating this 15 thousand lines of IR.

At least in debug mode we shouldn't be doing this for concrete types, but rather the destructor of Command should be compiled into the standard library and then crates which use it should link against this precompiled copy. I would go as far as to argue that this should almost always happen and only when instructed otherwise should the compiler inline destructors across crates (same as for all other methods).

cc @michaelwoerister, do you know if this was a deliberate decision, and is this perhaps something that's relatively easily fixed or something that would be much more intrusive to experiment with?

[alexcrichton]

For a smaller reproduction of this:

$ cat bar.rs
pub struct A(String);
$ cat foo.rs
pub fn a(_: bar::A) {}
$ rustc bar.rs --crate-type rlib
$ rustc foo.rs --crate-type rlib --extern bar=libbar.rlib --emit llvm-ir
$ wc -l foo.ll
980 foo.ll

where this is the generated LLVM IR

[michaelwoerister]

I remember that @arielb1 was tuning inline attributes for drop-glue at some point. It might have been deliberate but I don't remember anything that would make it necessary for correctness. It was probably just easier to implement that way. Seems like something that we should fix though.

[michaelwoerister]

It seems like #68414 might help fixing this but is not sufficient on its own because libstd is compiled with -Zshare-generics=no. I'll do experiments with changing that.

[jonas-schievink]

This seems like a duplicate of #38827

[Mark-Simulacrum]

Closing in favor of #38827, I agree this is a duplicate.