Code coverage reports wrong count of loop header

[pmur]

A simple test of the -C instrument-coverage feature returns the wrong count (9 instead of 10) of the loop header on line 4 when built with Rust 1.93.0:

main.rs:

fn main(){
    let mut sum: u32 = 0;

    for i in 1..10 {
        sum += i;
    }

    if false{
        println!("This code can't be reached");
    }
    println!("Sum: {}", sum);
}

Reproducer:

rustc -C instrument-coverage main.rs -o main
LLVM_PROFILE_FILE='testprof.profraw' ./main
llvm-profdata merge -sparse testprof.profraw -o testprof.profdata
llvm-cov show  main -instr-profile=testprof.profdata > coverage.out

This test works as expected with 1.92.0.

Meta

$ rustc +1.93.0 --version
rustc 1.93.0 (254b59607 2026-01-19)

[cuviper]

With 1.92.0 and earlier, it reported this loop coverage:

    4|     10|    for i in 1..10 {
    5|      9|        sum += i;
    6|      9|    }

With 1.93.0 and later:

    4|      9|    for i in 1..10 {
    5|      9|        sum += i;
    6|      9|    }

We expect a 10th hit on the first line for reaching the iterator's None.

[cuviper]

cargo-bisect-rust finds that the change occurred with #148465.

[cuviper]

Given #148465 (comment):

It's unfortunate that coverage instrumentation is so sensitive to desugaring, but the new coverage output doesn't seem any worse than the current output, just different.

@Zalathar do you think the difference here is expected as well? There really should be 10 calls to Iterator::next, 9 returning Some and 1 None, but it's not clear to me why the span change would lose that visibility.

Note that an empty loop does still count the loop header once:

    4|      1|    for i in 1..1 {
    5|      0|        sum += i;
    6|      0|    }

[Zalathar]

Hmm, in hindsight I think I was mistaken; this does seem worse.

I'll have to dig into the spans involved to see what's going on.

[Zalathar]

I think what's happening is that the coverage regions are capturing the binding to i (which happens 9 times) and the evaluation of IntoIterator::into_iter(1..10) (which happens once), but there is no surviving region that captures the Iterator::next call (which happens 10 times).