Change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --Take this simple crate: If I try to gather code coverage for , I end up with the first line mysteriously duplicated as a covered region: (I'm using for convenience, but the same thing happens when I use and process the coverage data manually with and .) Note that in the report produced by , the first line of the file appears twice. It is marked as having executed once, even though it is a comment. Instead, the line should only appear once, and its execution count (if any) should be the execution count of the actual code on that line. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<!-- <details<summaryBacktrace</summary<p</p</details--
I did some initial investigation, and discovered a few things: The coverage mapping that embeds in the test binary contains entries for two different functions named . One is the actual that appears in the file, and the other is the that is injected by the test harness. The mapping for the injected function spans from (1,0) to (1,1). Coverage mapping regions use 1-based line numbers and column numbers, so a column number of 0 should be impossible. This unexpected column number confuses the processing code in , and results in line 1 being duplicated in the output. : There are special circumstances where it's legal for a region to have 0 for its start column and its end column, but that isn't what's happening here.
The origin of the bogus (1,0) to (1,1) region seems to be: The test harness entry point is created with a dummy span: When that dummy span is converted into a region, its 0-based start is decremented in an attempt to make the region non-empty. This decrement overflows to , and a subsequent increment (to make it 1-based) overflows back to 0.
My first thought was to sidestep the whole issue by adding to the test harness's injected . However, I couldn’t get that to work, because is unstable and can't necessarily be used by the crate it is being injected into. So I think the fix will involve having the instrumentor detect and skip code with dummy spans.
label +A-code-coverage
fixes the overflow, which gets rid of the duplicate line. However, the instrumentor still ends up emitting an empty region from (1,1) to (1,1) for the test harness's , so I'd still like to find a way to avoid instrumenting that function.
I think the empty region now confusing the reporter in more subtle ways, because now I see weird stuff like this: It makes sense that line 1 is “covered” (via the injected ), but it's strange that lines 2 and 3 also have non-zero counts.
It looks like does have special handling for empty regions, but it doesn't properly anticipate the first region being empty, and ends up in a slightly confused state.

Discussion:
let expn_id = ext_cx.resolver.expansion_for_ast_pass( DUMMY_SP, AstPass::TestHarness, <del> &[sym::test, sym::rustc_attrs], </del> <ins> &[sym::test, sym::rustc_attrs, sym::no_coverage], </ins> None, ); let def_site = DUMMY_SP.with_def_site_ctxt(expn_id.to_expn_id());

// #[rustc_main] let main_attr = ecx.attr_word(sym::rustc_main, sp); <ins> // #[no_coverage] let no_coverage_attr = ecx.attr_word(sym::no_coverage, sp); </ins> // pub fn main() { ... } let main_ret_ty = ecx.ty(sp, ast::TyKind::Tup(ThinVec::new()));

let main = P(ast::Item { ident: main_id, <del> attrs: thin_vec![main_attr], </del> <ins> attrs: thin_vec![main_attr, no_coverage_attr], </ins> id: ast::DUMMY_NODE_ID, kind: main, vis: ast::Visibility { span: sp, kind: ast::VisibilityKind::Public, tokens: None },

}; fn a_test() {} #[rustc_main] <ins> #[no_coverage] </ins> pub fn main() -> () { extern crate test; test::test_main_static(&[&a_test, &m_test, &z_test])

<ins> 1|       |// Verify that the entry point injected by the test harness doesn't cause 2|       |// weird artifacts in the coverage report (e.g. issue #10749). 3|       | 4|       |// compile-flags: --test 5|       | 6|       |#[allow(dead_code)] 7|      0|fn unused() {} 8|       | 9|      1|#[test] 10|      1|fn my_test() {} </ins>

<ins> // Verify that the entry point injected by the test harness doesn't cause // weird artifacts in the coverage report (e.g. issue #10749). // compile-flags: --test #[allow(dead_code)] fn unused() {} #[test] fn my_test() {} </ins>