-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 7 pull requests #124855
Closed
Closed
Rollup of 7 pull requests #124855
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This code for recalculating `mcdc_bitmap_bytes` 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.
These comments appear to be inspired by the similar comments on `CounterIncrement` and `ExpressionUsed`. But those comments refer to specific simplification steps performed during coverage codegen, and there is no corresponding step for the MC/DC coverage statements.
This field counts the number of conditions that contribute to a particular decision, but the name "conditions num" sounds like an ID instead of a count, so "num conditions" is clearer.
…onst, r=compiler-errors Do not ICE on `AnonConst`s in `diagnostic_hir_wf_check` Fixes rust-lang#122989 Below is the snippet from rust-lang#122989 that ICEs: ```rust trait Traitor<const N: N<2> = 1, const N: N<2> = N> { fn N(&N) -> N<2> { M } } trait N<const N: Traitor<2> = 12> {} ``` The `AnonConst` that triggers the ICE is the `2` in the param `const N: N<2> = 1`. The currently existing code in `diagnostic_hir_wf_check` deals only with `AnonConst`s that are default values of some param, but the `2` is not a default value. It is just an `AnonConst` HIR node inside a `TraitRef` HIR node corresponding to `N<2>`. Therefore the existing code cannot handle it and this PR ensures that it does.
…er-errors coverage: Branch coverage support for let-else and if-let This PR adds branch coverage instrumentation for let-else and if-let, including let-chains. This lifts two of the limitations listed at rust-lang#124118.
…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.)
…tmcm next_power_of_two: add a doctest to show what happens on 0
rustbot
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
rollup
A PR which is a rollup
labels
May 7, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
rollup
A PR which is a rollup
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
AnonConst
s indiagnostic_hir_wf_check
#124219 (Do not ICE onAnonConst
s indiagnostic_hir_wf_check
)mcdc_bitmap_bytes
andconditions_num
#124571 (coverage: Clean upmcdc_bitmap_bytes
andconditions_num
)rustc_parse::lexer
#124832 (narrow down visibilities inrustc_parse::lexer
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup