…r-errors

coverage: Clean up `mcdc_bitmap_bytes` and `conditions_num`

This is a combination of two mostly-separate MC/DC coverage cleanups that would conflict with each other, plus some extra tests that appeared along the way.

The first change is to stop recomputing `mcdc_bitmap_bytes` in the query that produces `CoverageIdsInfo`. This appears to have been inspired by how we were already computing `max_counter_id`, but there's an important difference between the two cases.

When computing `max_counter_id`, the highest counter ID seen might be less than the highest ID used during MIR instrumentation, because some counter-increment statements might have been removed by MIR optimizations.

But for the recomputation used for `mcdc_bitmap_bytes`, that's impossible, because both computations are based on pre-optimization info. So there's no need to recompute the exact same value, when it can't have changed

---

The second change is to rename `conditions_num` to `num_conditions`, to make it clearer that this refers to a *number of conditions*, not some kind of ID number.

Because this change touched the compiler warning for a decision containing too many conditions, I also noticed that we didn't have any tests for that warning.

(It now seems a bit strange to me that this is a compiler warning, not a lint, because it can't be silenced or denied by the usual mechanisms for controlling lints. But I consider that change to be beyond the scope of this PR.)

…r-errors

coverage: Clean up `mcdc_bitmap_bytes` and `conditions_num`

This is a combination of two mostly-separate MC/DC coverage cleanups that would conflict with each other, plus some extra tests that appeared along the way.

The first change is to stop recomputing `mcdc_bitmap_bytes` in the query that produces `CoverageIdsInfo`. This appears to have been inspired by how we were already computing `max_counter_id`, but there's an important difference between the two cases.

When computing `max_counter_id`, the highest counter ID seen might be less than the highest ID used during MIR instrumentation, because some counter-increment statements might have been removed by MIR optimizations.

But for the recomputation used for `mcdc_bitmap_bytes`, that's impossible, because both computations are based on pre-optimization info. So there's no need to recompute the exact same value, when it can't have changed

---

The second change is to rename `conditions_num` to `num_conditions`, to make it clearer that this refers to a *number of conditions*, not some kind of ID number.

Because this change touched the compiler warning for a decision containing too many conditions, I also noticed that we didn't have any tests for that warning.

(It now seems a bit strange to me that this is a compiler warning, not a lint, because it can't be silenced or denied by the usual mechanisms for controlling lints. But I consider that change to be beyond the scope of this PR.)

…iaskrgr

Rollup of 3 pull requests

Successful merges:

 - rust-lang#124223 (coverage: Branch coverage support for let-else and if-let)
 - rust-lang#124571 (coverage: Clean up `mcdc_bitmap_bytes` and `conditions_num`)
 - rust-lang#124838 (next_power_of_two: add a doctest to show what happens on 0)

r? `@ghost`
`@rustbot` modify labels: rollup

…errors

coverage: Clean up `mcdc_bitmap_bytes` and `conditions_num`

This is a combination of two mostly-separate MC/DC coverage cleanups that would conflict with each other, plus some extra tests that appeared along the way.

The first change is to stop recomputing `mcdc_bitmap_bytes` in the query that produces `CoverageIdsInfo`. This appears to have been inspired by how we were already computing `max_counter_id`, but there's an important difference between the two cases.

When computing `max_counter_id`, the highest counter ID seen might be less than the highest ID used during MIR instrumentation, because some counter-increment statements might have been removed by MIR optimizations.

But for the recomputation used for `mcdc_bitmap_bytes`, that's impossible, because both computations are based on pre-optimization info. So there's no need to recompute the exact same value, when it can't have changed

---

The second change is to rename `conditions_num` to `num_conditions`, to make it clearer that this refers to a *number of conditions*, not some kind of ID number.

Because this change touched the compiler warning for a decision containing too many conditions, I also noticed that we didn't have any tests for that warning.

(It now seems a bit strange to me that this is a compiler warning, not a lint, because it can't be silenced or denied by the usual mechanisms for controlling lints. But I consider that change to be beyond the scope of this PR.)

…hercote

coverage: `CoverageIdsInfo::mcdc_bitmap_bytes` is never needed

This code for recalculating `mcdc_bitmap_bytes` in a query doesn't provide any benefit, because its result won't have changed from the value in `FunctionCoverageInfo` that was computed during the MIR instrumentation pass.

Extracted from rust-lang#124571, to avoid having this held up by unrelated issues with condition count checks.

`@rustbot` label +A-code-coverage

Rollup merge of rust-lang#125108 - Zalathar:info-bitmap-bytes, r=nnethercote

coverage: `CoverageIdsInfo::mcdc_bitmap_bytes` is never needed

This code for recalculating `mcdc_bitmap_bytes` in a query doesn't provide any benefit, because its result won't have changed from the value in `FunctionCoverageInfo` that was computed during the MIR instrumentation pass.

Extracted from rust-lang#124571, to avoid having this held up by unrelated issues with condition count checks.

`@rustbot` label +A-code-coverage

…cote

coverage: Avoid overflow when the MC/DC condition limit is exceeded

Fix for the test failure seen in rust-lang#124571 (comment).

If we perform this subtraction first, it can sometimes overflow to -1 before the addition can bring its value back to 0.

That behaviour seems to be benign, but it nevertheless causes test failures in compiler configurations that check for overflow.

`@rustbot` label +A-code-coverage

…cote

coverage: Avoid overflow when the MC/DC condition limit is exceeded

Fix for the test failure seen in rust-lang#124571 (comment).

If we perform this subtraction first, it can sometimes overflow to -1 before the addition can bring its value back to 0.

That behaviour seems to be benign, but it nevertheless causes test failures in compiler configurations that check for overflow.

``@rustbot`` label +A-code-coverage

Rollup merge of rust-lang#125700 - Zalathar:limit-overflow, r=nnethercote

coverage: Avoid overflow when the MC/DC condition limit is exceeded

Fix for the test failure seen in rust-lang#124571 (comment).

If we perform this subtraction first, it can sometimes overflow to -1 before the addition can bring its value back to 0.

That behaviour seems to be benign, but it nevertheless causes test failures in compiler configurations that check for overflow.

``@rustbot`` label +A-code-coverage

coverage: Rename MC/DC `conditions_num` to `num_conditions`

Updated version of rust-lang#124571, without the other changes that were split out into rust-lang#125108 and rust-lang#125700.

This value represents a quantity of conditions, not an ID, so the new spelling is more appropriate.

Some of the code touched by this PR could perhaps use some other changes, but I would prefer to keep this PR as a simple renaming and avoid scope creep.

`@rustbot` label +A-code-coverage

Rollup merge of rust-lang#125754 - Zalathar:conditions-num, r=lqd

coverage: Rename MC/DC `conditions_num` to `num_conditions`

Updated version of rust-lang#124571, without the other changes that were split out into rust-lang#125108 and rust-lang#125700.

This value represents a quantity of conditions, not an ID, so the new spelling is more appropriate.

Some of the code touched by this PR could perhaps use some other changes, but I would prefer to keep this PR as a simple renaming and avoid scope creep.

`@rustbot` label +A-code-coverage