Dead code not linked in beta or nightly

[xd009642]

I've noticed with beta and nightly the rust flag link-dead-code no longer includes unused source files when running cargo test. Testing it out on this test project, I used objdump -WL to get the decoded lines in the binary. With rustc stable both source files in the crate are linked into the test binary (lib.rs and unused.rs), however with stable and nightly only lib.rs is linked.

This is counter to what I'd expect link-dead-code to do. Is this a desired feature? And if so is there the means to obtain the old behaviour?

[Mark-Simulacrum]

Probably a regression related to ThinLTO work... Cc @alexcrichton

[alexcrichton]

My guess is this is #45575 (cc @michaelwoerister) rather than ThinLTO b/c the mention of cargo test here I think indicates debug mode?

[michaelwoerister]

My guess is this is #45575 (cc @michaelwoerister) rather than ThinLTO

Yes, that could well be. We still would need to decide whether link-dead-code is supposed to also generate dead code (as opposed to what the name implies in a strict sense).

[nikomatsakis]

Discussed in @rust-lang/compiler meeting. Consensus was that -Clink-dead-code should make compiler generate dead code, as it used to, since there isn't much value in just having the linker preserve dead code (but not having compiler generate it). We considered changing the name but decided that was more trouble than it's worth, and it'd be better to just adjust the -Chelp message to clarify.

[nikomatsakis]

triage: P-high

[xd009642]

Did the associated PR for this manage to make it into 1.23? I'm only asking because I just updated my stable and this issue still seems to be present.

[michaelwoerister]

Unfortunately, the PR did not make it into 1.23. Version 1.24 will contain the patch though.

In the @rust-lang/compiler meeting we discussed if it would make sense to make a 1.23.1 release that includes the PR, but concluded that we won't do that since support for code coverage tools is not considered production quality yet.

@xd009642, would you mind testing your project with the latest nightly? This is the first version that includes the patch.

[xd009642]

Just tested with nightly and it works, thanks.

[michaelwoerister]

Thank you, @xd009642!

[nikomatsakis]

@xd009642 is it a problem for you to use nightly for a bit until this fix propagates?

[xd009642]

So personally it's not a problem for me, however I make an application with users so this does impact the user experience. I've put a note at the top of the project readme which will hopefully mitigate any issues people face and the early February release date for 1.24 lessens the impact as well.

RE the support for code coverage tools not being considered production quality, I do think there is a slight difference between being something supported by the compiler (in a production ready form) versus being hampered by the compiler. For example, if I was to mitigate this in my tool I'd have to increase the impact of the syntax analysis portion to identity code the compiler may miss out and issue a release just for 1.23. So while it's not supported by rustc, rustc has impinged code coverage tools.

Personally, I don't think there's a big issue tarpaulin-wise, since it's just a nightly run away from expected behaviour. People choosing to use kcov etc. will find that their coverage tools suddenly don't work as expected and they're getting a lot of false negatives.

I don't want to sound too negative, this is a small thing language-wise, it's just a big thing in code coverage. I trust the rust team will make the right decision for users and am a big fan of the work you guys are doing 😄