Work around missing code coverage data causing llvm-cov failures

[wesleywiser]

If we do not add code coverage instrumentation to the Body of a
function, then when we go to generate the function record for it, we
won't write any data and this later causes llvm-cov to fail when
processing data for the entire coverage report.

I've identified two main cases where we do not currently add code
coverage instrumentation to the Body of a function:

1. If the function has a single BasicBlock and it ends with a
   TerminatorKind::Unreachable.

2. If the function is created using a proc macro of some kind.

For case 1, this is typically not important as this most often occurs as
a result of function definitions that take or return uninhabited
types. These kinds of functions, by definition, cannot even be called so
they logically should not be counted in code coverage statistics.

For case 2, I haven't looked into this very much but I've noticed while
testing this patch that (other than functions which are covered by case

1. the skipped function coverage debug message is occasionally triggered
   in large crate graphs by functions generated from a proc macro. This may
   have something to do with weird spans being generated by the proc macro
   but this is just a guess.

I think it's reasonable to land this change since currently, we fail to
generate any results from llvm-cov when a function has no coverage
instrumentation applied to it. With this change, we get coverage data
for all functions other than the two cases discussed above.

Fixes #93054 which occurs because of uncallable functions which shouldn't
have code coverage anyway.

I will open an issue for missing code coverage of proc macro generated
functions and leave a link here once I have a more minimal repro.

r? @tmandry
cc @richkadel

[wesleywiser]

Just FYI, I spent a good chunk of today trying a different approach to resolve this issue which was to identify functions that are uncallable and filter them out before we call define_unused_fn on them. That change ended up being much more complex, didn't do anything for proc macro generated functions and caused an incremental compilation ICE that I wasn't able to track down.

Given those factors, this seemed like the better approach to me as we shouldn't be generating invalid (empty) coverage_mapping_buffer values anyway which is what leads to llvm-cov failing with the "Truncated coverage data" error.

[richkadel]

Looks good to me.

I guess we still have the side effect of adding the unused function stubs without including them in coverage; but as I said, the process for computing the counter_regions is somewhat complex, and not easily cacheable, so I think this should work for now.

I'll file and issue to see if I can improve it so we can avoid adding the function.

Thanks Wesley!

[tmandry]

@bors r+ rollup

[bors]

📌 Commit 1a0278e has been approved by tmandry