Don't generate code for unused #[inline] function

[retep998]

If a function or method is marked #[inline] and it isn't actually called anywhere in that crate, then no code should be generated for it. This would save a lot of time on translation and LLVM passes for certain crates, such as winapi.

@eddyb told me to open this issue. Blame him.

[eddyb]

cc @rust-lang/compiler - especially @michaelwoerister, I believe the collector should be able to reliably detect whether an #[inline] function is actually used, the only change needed to get this behavior (if we want it) would be to not use #[inline] functions as roots in the collector.

[michaelwoerister]

Afaict, the only thing that needs to be adapted should be TransItem::is_instantiated_only_on_demand(). There's also TransItem::requests_inline() which makes it easy to check for the #[inline] attribute.

[retep998]

I did a simple patch which changed that function and it didn't really affect compile times. In fact the LLVM IR is just as big, leading me to conclude that there is more going on to decide whether to instantiate something than that function.

I'll let someone else take it from here because this is beyond my knowledge of rustc: retep998@e8d9b86

[michaelwoerister]

@retep998 Do you have an example of a function that you would expect not to be generated?

[retep998]

@michaelwoerister For example a simple #[inline] pub fn foo() {}. Or perhaps a trait impl impl Clone for Foo { #[inline] fn clone(&self) -> Foo { *Foo } }. According to a quick test, doing --emit=llvm-ir with a rustc built with my patch, functions defined like that in winapi are still being generated.

[michaelwoerister]

For example a simple #[inline] pub fn foo() {}.

If the function isn't used or referenced anywhere in the crate then the modification you made should have done the trick. I'll take a look when I find the time.

[michaelwoerister]

I'm removing the nominated tag, this doesn't really need discussion in the meeting, it should just be investigated and fixed.

[michaelwoerister]

While investigating #36309 I figured out why the fix suggested above didn't help: it only fixes the problem on the multiple-codegen-units-path. For it to work with just one codegen-unit, the change will be a bit more complicated, but it will probably be part of the fix for #36309.