[Coverage][MCDC] Do not initialize mcdc parameters for instances containing no mcdc statements

[Lambdaris]

This patch fixes possible panics when compiling with mcdc instruments.

The trace of the panic is:

1. The compiler inserts mcdc statements and fullfill function_coverage_info in pass InstrumentCoverage.
2. In pass StateTransform, a new DropGlue instance is created at create_coroutine_drop_shim, where function_coverage_info is cloned. Then at remove_dead_blocks, all coverage statements are removed.
3. In init_coverage the compiler inserts intrinsic instrprof.mcdc.parameters since the DropGlue instance has function_coverage_info with positive mcdc_bitmap_bytes. Note this instance has no coverage statements, so there are no other profiling intrinsics inserted later.
4. In containsProfilingIntrinsics, llvm possibly finds that the module containing the illformed instance has no expected profiling instrinsics, thus it early returns in InstrLowerer::lower, leaving instrprof.mcdc.parameters unchanged. (The expected instrinsics are declared once there is a instance lowering statement CounterIncrement. However if the module unluckily had no such instance, llvm definitely can not find those intrinsics)
5. Finally llvm visits intrprof.mcdc.paratemers at codegen, and reaches the unexpected case in SelectionDAGBuilder::visitIntrinsicCall.

These kind of panics may disappear with change of the value passed to -C metadata, because the metadata hash affects sort of instances hence such instances can be grouped with other instrumented instances together into a codegen unit in which llvm can find instrprof.increment at step 4.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nnethercote (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[rustbot]

Some changes occurred in coverage instrumentation.

cc @Zalathar

[Lambdaris]

@rustbot label +A-code-coverage
r? Zalathar

[bors]

☔ The latest upstream changes (presumably #130724) made this pull request unmergeable. Please resolve the merge conflicts.

[Lambdaris]

In case this pr was missed, @Zalathar

[Zalathar]

Sorry for the delay.

Is there a test case that can trigger this panic in the current compiler? It would be good to have a regression test so that we can modify the code without worrying about breaking things again.

[Lambdaris]

Is there a test case that can trigger this panic in the current compiler? It would be good to have a regression test so that we can modify the code without worrying about breaking things again.

Have tried but it looks hard. This bug happens only when:

1. The function is complicated enough for a DropGlue.
2. The hash context is just right so that the DropGlue function is grouped into a codegen unit in which no other functions are instrumented coverage instrinsics (even its primary function). The hash context is determined by StableCrateId, which is created by not only the value passed to -C metadata but also the cfg_version of rustc itself.

I encountered this issue when compiling parallel::job_token::inherited_jobserver::ActiveJobServer::acquire in cc with a local developing rustc. However I can not reproduce it with the latest nightly rustc though we can believe with some value of metadata could.

[Lambdaris]

Check such instances with CounterIncrement instruments in case all mcdc regions were just folded. 08f0d64