about summary refs log tree commit diff
path: root/compiler/rustc_codegen_llvm
diff options
context:
space:
mode:
authorMatthias Krüger <matthias.krueger@famsik.de>2022-01-25 05:51:11 +0100
committerGitHub <noreply@github.com>2022-01-25 05:51:11 +0100
commit8dddc8647731efb6d7f40b176bccdba5cebe46f2 (patch)
tree6ea91de61a8fa173f5824ef3d15bd646e3e9ad11 /compiler/rustc_codegen_llvm
parentc8ede152a522fcf139b35700b36ec3e788617857 (diff)
parent1a0278e1d17f66ddc5975f38387746f85c6602ce (diff)
downloadrust-8dddc8647731efb6d7f40b176bccdba5cebe46f2.tar.gz
rust-8dddc8647731efb6d7f40b176bccdba5cebe46f2.zip
Rollup merge of #93144 - wesleywiser:uninhabited_type_code_cov2, r=tmandry
Work around missing code coverage data causing llvm-cov failures

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``
Diffstat (limited to 'compiler/rustc_codegen_llvm')
-rw-r--r--compiler/rustc_codegen_llvm/src/coverageinfo/mapgen.rs17
1 files changed, 13 insertions, 4 deletions
diff --git a/compiler/rustc_codegen_llvm/src/coverageinfo/mapgen.rs b/compiler/rustc_codegen_llvm/src/coverageinfo/mapgen.rs
index 32f18419753..3014d2f1930 100644
--- a/compiler/rustc_codegen_llvm/src/coverageinfo/mapgen.rs
+++ b/compiler/rustc_codegen_llvm/src/coverageinfo/mapgen.rs
@@ -9,6 +9,7 @@ use rustc_data_structures::fx::FxIndexSet;
 use rustc_hir::def::DefKind;
 use rustc_hir::def_id::DefIdSet;
 use rustc_llvm::RustString;
+use rustc_middle::bug;
 use rustc_middle::middle::codegen_fn_attrs::CodegenFnAttrFlags;
 use rustc_middle::mir::coverage::CodeRegion;
 use rustc_middle::ty::TyCtxt;
@@ -76,10 +77,18 @@ pub fn finalize<'ll, 'tcx>(cx: &CodegenCx<'ll, 'tcx>) {
         let coverage_mapping_buffer = llvm::build_byte_buffer(|coverage_mapping_buffer| {
             mapgen.write_coverage_mapping(expressions, counter_regions, coverage_mapping_buffer);
         });
-        debug_assert!(
-            !coverage_mapping_buffer.is_empty(),
-            "Every `FunctionCoverage` should have at least one counter"
-        );
+
+        if coverage_mapping_buffer.is_empty() {
+            if function_coverage.is_used() {
+                bug!(
+                    "A used function should have had coverage mapping data but did not: {}",
+                    mangled_function_name
+                );
+            } else {
+                debug!("unused function had no coverage mapping data: {}", mangled_function_name);
+                continue;
+            }
+        }
 
         function_data.push((mangled_function_name, source_hash, is_used, coverage_mapping_buffer));
     }