-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
[Coverage][MCDC] Prepare MCDC Builder for pattern matching and llvm 19 #126677
Conversation
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt Some changes occurred in coverage tests. cc @Zalathar Some changes occurred in coverage instrumentation. cc @Zalathar Some changes occurred in coverage instrumentation. cc @Zalathar Some changes occurred in coverage instrumentation. cc @Zalathar |
cc @RenjiSann |
@rustbot label +A-code-coverage |
By the way, I think the MC/DC limit warnings should probably be lints instead of ordinary warnings, so that they interact with the I don't think that concern should block this PR, but we should remember to fix it at some point. |
That's meaningful. #82448 also introduces two options to control the limit. I think we can fix that with these options once llvm-19 is released. |
0d23d53
to
8712975
Compare
☔ The latest upstream changes (presumably #127174) made this pull request unmergeable. Please resolve the merge conflicts. |
8712975
to
61b608c
Compare
Some changes occurred in match lowering cc @Nadrieril |
Some commits are shared with #127234 now. I wish to merge that first. |
☔ The latest upstream changes (presumably #127360) made this pull request unmergeable. Please resolve the merge conflicts. |
a49e7b2
to
becc530
Compare
becc530
to
1e6e3fb
Compare
&hir_info, | ||
&mut extracted_mappings, | ||
&basic_coverage_blocks, | ||
&mut coverage_counters, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been thinking about this &mut coverage_counters
, because I did the same thing in my draft of #124154, but now I think it's the wrong approach.
Instead, I think we should try to teach CoverageCounters::make_bcb_counters
how to create the complex expressions that will be needed later, so that all the counter-creation happens together.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then some keys may be essential to mappings so that we can get these sum expressions from coverage_counters
later, sounds a bit redundant.
Currently we only need to create Expression
but not Counter
here. What are the drawbacks of the current approach?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After some more thought, I think it's OK to do this for now.
I still have mixed feelings about it, but I don't know what the specific alternative should look like, and I don't think this change should have to wait for me to figure that out.
I would add commit for each fix. After all are done I will squash them into the primary commits (the target commits are hinted at head of the message) |
This comment has been minimized.
This comment has been minimized.
37f9ad8
to
97596dd
Compare
coverage: Restrict `ExpressionUsed` simplification to `Code` mappings In the future, branch and MC/DC mappings might have expressions that don't correspond to any single point in the control-flow graph. That makes it trickier to keep track of which expressions should expect an `ExpressionUsed` node. We therefore sidestep that complexity by only performing `ExpressionUsed` simplification for expressions associated directly with ordinary `Code` mappings. (This simplification step is inherited from the original coverage implementation, which only supported `Code` mappings anyway, so there's no particular reason to extend it to other kinds of mappings unless we specifically choose to.) Relevant to: - rust-lang#124154 - rust-lang#126677 - rust-lang#124278 `@rustbot` label +A-code-coverage
coverage: Restrict `ExpressionUsed` simplification to `Code` mappings In the future, branch and MC/DC mappings might have expressions that don't correspond to any single point in the control-flow graph. That makes it trickier to keep track of which expressions should expect an `ExpressionUsed` node. We therefore sidestep that complexity by only performing `ExpressionUsed` simplification for expressions associated directly with ordinary `Code` mappings. (This simplification step is inherited from the original coverage implementation, which only supported `Code` mappings anyway, so there's no particular reason to extend it to other kinds of mappings unless we specifically choose to.) Relevant to: - rust-lang#124154 - rust-lang#126677 - rust-lang#124278 ``@rustbot`` label +A-code-coverage
coverage: Restrict `ExpressionUsed` simplification to `Code` mappings In the future, branch and MC/DC mappings might have expressions that don't correspond to any single point in the control-flow graph. That makes it trickier to keep track of which expressions should expect an `ExpressionUsed` node. We therefore sidestep that complexity by only performing `ExpressionUsed` simplification for expressions associated directly with ordinary `Code` mappings. (This simplification step is inherited from the original coverage implementation, which only supported `Code` mappings anyway, so there's no particular reason to extend it to other kinds of mappings unless we specifically choose to.) Relevant to: - rust-lang#124154 - rust-lang#126677 - rust-lang#124278 ```@rustbot``` label +A-code-coverage
Rollup merge of rust-lang#127758 - Zalathar:expression-used, r=oli-obk coverage: Restrict `ExpressionUsed` simplification to `Code` mappings In the future, branch and MC/DC mappings might have expressions that don't correspond to any single point in the control-flow graph. That makes it trickier to keep track of which expressions should expect an `ExpressionUsed` node. We therefore sidestep that complexity by only performing `ExpressionUsed` simplification for expressions associated directly with ordinary `Code` mappings. (This simplification step is inherited from the original coverage implementation, which only supported `Code` mappings anyway, so there's no particular reason to extend it to other kinds of mappings unless we specifically choose to.) Relevant to: - rust-lang#124154 - rust-lang#126677 - rust-lang#124278 ```@rustbot``` label +A-code-coverage
This comment has been minimized.
This comment has been minimized.
06bc597
to
c42a016
Compare
…n and change the way to calculate decision depth
…gs and support multiple branch markers
c42a016
to
bc11434
Compare
It's not clear to me which parts of this are for LLVM 19, which parts are for pattern matching, and why they are combined in one PR. Is there some reason why the changes needed for LLVM 19 can't proceed separately from the changes needed for pattern matching? |
The change for llvm 19 is group decision and its conditions to
No, actually they can be separated indeed as long as we separate degraded mcdc branches from mcdc spans early, as the change introduced at the last commit of this pr. So I worked on patches for llvm 19 based this. |
I have separated all work for llvm-19, this pr is no longer needed. Pattern matching will still be based on that. |
Prepare for pattern matching decisions and adaption to llvm-19.
Changes
MCDCBuilder
is refactored. The main change is the way to calculate depth of decisions and thatDecisionCtx
is responsible to process decisions (for now we have justBooleanDecisionCtx
, while in Support mcdc analysis for pattern matching #124278 we introduceMatchingDecisionCtx
). We useMCDCState
to store context processing decisions. If a nested decision is to be introduced, the parent's state will be "stashed" and a new state will be created for the nested decision. Once the nested decision is finished the parent's state is "unstashed" and states for nested decisions will be removed later. The new mechanism can fix that nested decisions in top-level boolean expressions likea || func(b && c)
can not be processed properly by current nightly compiler, as tests innested_in_boolean_exprs.rs
.MCDCBranchSpan
andMCDCBranch
can hold multiple true markers or false markers. This is for matching patterns.