Skip to content
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

Split mcdc code to a sub module of coverageinfo #124399

Merged
merged 3 commits into from Apr 30, 2024
Merged

Conversation

ZhuUx
Copy link
Contributor

@ZhuUx ZhuUx commented Apr 26, 2024

A further work from #124217 . I have made relatively large changes when working on #124278 so that it would better split them from coverageinfo.rs to avoid potential troubling merge work with improved branch coverage by @Zalathar .

Besides BlockMarkerGenerator is added to avoid ownership problems (mostly needed for following change of #124278 )

All code changes are done in a37d737a while the second commit just renames the file.

cc @RenjiSann @Zalathar
This will impact your current work.

@rustbot
Copy link
Collaborator

rustbot commented Apr 26, 2024

r? @estebank

rustbot has assigned @estebank.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot 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. labels Apr 26, 2024
@rustbot
Copy link
Collaborator

rustbot commented Apr 26, 2024

Some changes occurred in coverage instrumentation.

cc @Zalathar

@ZhuUx
Copy link
Contributor Author

ZhuUx commented Apr 26, 2024

r? @oli-obk

@rustbot rustbot assigned davidtwco, oli-obk and lcnr and unassigned estebank, davidtwco, oli-obk and lcnr Apr 26, 2024
@Zalathar
Copy link
Contributor

Hmm, I think I would prefer to leave the main file as coverageinfo.rs, without changing it to coverageinfo/mod.rs.

Moving the MC/DC code into a subdirectory is still fine, but we should consider delaying this change until after I've had a chance to review and merge #124255, to avoid disturbing that work too much.

@oli-obk
Copy link
Contributor

oli-obk commented Apr 26, 2024

@bors delegate=Zalathar

@bors
Copy link
Contributor

bors commented Apr 26, 2024

✌️ @Zalathar, you can now approve this pull request!

If @oli-obk told you to "r=me" after making some further change, please make that change, then do @bors r=@oli-obk

@ZhuUx
Copy link
Contributor Author

ZhuUx commented Apr 26, 2024

Hmm, I think I would prefer to leave the main file as coverageinfo.rs, without changing it to coverageinfo/mod.rs.

I'm not sure whether rustc accept the new module style so I kept it same with other modules. If could the second commit can be dropped.

Moving the MC/DC code into a subdirectory is still fine, but we should consider delaying this change until after I've had a chance to review and merge #124255, to avoid disturbing that work too much.

Sounds fair.

@rustbot
Copy link
Collaborator

rustbot commented Apr 29, 2024

Some changes occurred in coverage instrumentation.

cc @Zalathar

Some changes occurred in coverage instrumentation.

cc @Zalathar

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred in coverage instrumentation.

cc @Zalathar

Some changes occurred in match lowering

cc @Nadrieril

Some changes occurred in coverage tests.

cc @Zalathar

@bors
Copy link
Contributor

bors commented Apr 29, 2024

☔ The latest upstream changes (presumably #124255) made this pull request unmergeable. Please resolve the merge conflicts.

@ZhuUx ZhuUx force-pushed the split-mcdc branch 2 times, most recently from d42431b to 035e0a8 Compare April 30, 2024 01:46
@Zalathar
Copy link
Contributor

Would it be reasonable to split this into two commits, so that the first commit adds BlockMarkerGen (and maybe makes other adjustments) without moving anything, and the second commit only moves code without modifying anything?

(Similar to what I've done in #124545, by having a preparation commit first, and then a movement-only commit second.)

@ZhuUx
Copy link
Contributor Author

ZhuUx commented Apr 30, 2024

Would it be reasonable to split this into two commits, so that the first commit adds BlockMarkerGen (and maybe makes other adjustments) without moving anything, and the second commit only moves code without modifying anything?

(Similar to what I've done in #124545, by having a preparation commit first, and then a movement-only commit second.)

Sure will do


use crate::build::{Builder, CFG};
use crate::errors::MCDCExceedsConditionNumLimit;
use mcdc::MCDCInfoBuilder;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Please make this use crate::build::coverageinfo::mcdc::MCDCInfoBuilder, so that all the same-crate imports are consistent.

(I don't think there's an official policy for this formatting, but personally I prefer the consistent style.)

tcx.sess
.instrument_coverage_mcdc()
.then(|| Self { decision_ctx_stack: vec![MCDCDecisionCtx::default()] })
fn init() -> Self {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: This should just be new().

@Zalathar
Copy link
Contributor

I have some suggestions for renaming things. These are just suggestions, so you might disagree.

  • block_marker_gen can be markers (but BlockMarkerGen is fine)
  • mcdc_builder can be mcdc (but MCDCInfoBuilder is fine)

The reason for these suggestions is that I think the shorter variable names make the code easier to read, and the longer names don't add much useful information.

What do you think?

@ZhuUx
Copy link
Contributor Author

ZhuUx commented Apr 30, 2024

I have some suggestions for renaming things. These are just suggestions, so you might disagree.

* `block_marker_gen` can be `markers` (but `BlockMarkerGen` is fine)

* `mcdc_builder` can be `mcdc` (but `MCDCInfoBuilder` is fine)

The reason for these suggestions is that I think the shorter variable names make the code easier to read, and the longer names don't add much useful information.

What do you think?

Agree that markers is better. While I'd prefer to mcdc_builder or mcdc_info but not just mcdc because mcdc might be too short to indicate what the field does for mcdc.

Comment on lines 438 to 451
if let Some(mcdc_info) = self
.coverage_branch_info
.as_mut()
.and_then(|branch_info| branch_info.mcdc_info.as_mut())
{
mcdc_state.record_conditions(logical_op, span);
mcdc_info.state.record_conditions(logical_op, span);
}
}

pub(crate) fn mcdc_increment_depth_if_enabled(&mut self) {
if let Some(branch_info) = self.coverage_branch_info.as_mut()
&& let Some(mcdc_state) = branch_info.mcdc_state.as_mut()
if let Some(mcdc_info) = self
.coverage_branch_info
.as_mut()
.and_then(|branch_info| branch_info.mcdc_info.as_mut())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think using let chains (&& let) here is clearer than using and_then.

@Zalathar
Copy link
Contributor

Typo in commit name:

  • Add MCDCInfoBuilder to isolate all mcdc staff from BranchInfoBuilder
    • “staff” → “stuff”

@Zalathar
Copy link
Contributor

I'm not convinced that changing things from .expect(..) to bug! is an improvement, but I think I won't worry about that, because it's pretty minor and I don't want to keep asking you to make small changes that require you to re-do the split.

@ZhuUx
Copy link
Contributor Author

ZhuUx commented Apr 30, 2024

I'm not convinced that changing things from .expect(..) to bug! is an improvement, but I think I won't worry about that, because it's pretty minor and I don't want to keep asking you to make small changes that require you to re-do the split.

I change expect to bug! because it is not very obvious that the decision_ctx_stack is always non empty when needed. I want to report it with bug! to get a nicer output in case the invariant were broken with following development. We could change it back to expect if mcdc is stable to some extent.

@Zalathar
Copy link
Contributor

OK, this looks good.

@bors r=Zalathar

@bors
Copy link
Contributor

bors commented Apr 30, 2024

📌 Commit 6c8b492 has been approved by Zalathar

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 30, 2024
@Zalathar
Copy link
Contributor

@rustbot label +A-code-coverage

@rustbot rustbot added the A-code-coverage Area: Source-based code coverage (-Cinstrument-coverage) label Apr 30, 2024
@bors
Copy link
Contributor

bors commented Apr 30, 2024

⌛ Testing commit 6c8b492 with merge 47314eb...

@bors
Copy link
Contributor

bors commented Apr 30, 2024

☀️ Test successful - checks-actions
Approved by: Zalathar
Pushing 47314eb to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Apr 30, 2024
@bors bors merged commit 47314eb into rust-lang:master Apr 30, 2024
10 checks passed
@rustbot rustbot added this to the 1.80.0 milestone Apr 30, 2024
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (47314eb): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.1% [0.1%, 0.1%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.1% [0.1%, 0.1%] 1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 672.74s -> 672.522s (-0.03%)
Artifact size: 316.01 MiB -> 315.99 MiB (-0.00%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-code-coverage Area: Source-based code coverage (-Cinstrument-coverage) merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants