Spurious failure in coverage report test

[RalfJung]

In #83257 (comment), run-make-fulldeps\coverage-reports failed on x86_64-msvc-1 even though the PR just bumped the Miri submodule -- so this has to be a spurious failure, right?

@rust-lang/infra maybe you have a good idea for whom to ping about this.

[RalfJung]

Cc'ing some people who worked on that test: @richkadel @tmiasko

[richkadel]

The MIR pass produced from -Zinstrument-coverage did produce different results, on Windows.

--- expected_show_coverage.doctest.txt	2021-03-18 13:45:52.989271700 +0000
+++ /d/a/rust/rust/build/x86_64-pc-windows-msvc/test/run-make-fulldeps/coverage-reports/coverage-reports/actual_show_coverage.doctest.txt	2021-03-18 14:40:14.025645000 +0000
@@ -74,13 +74,13 @@
    70|      1|/// doctest_crate::fn_run_in_doctests(3);
    71|      1|/// ```
    72|       |///
-   73|      1|fn main() {
-   74|      1|    if true {
-   75|      1|        assert_eq!(1, 1);
+   73|       |fn main() {
+   74|       |    if true {
+   75|       |        assert_eq!(1, 1);
    76|       |    } else {
    77|       |        assert_eq!(1, 2);
    78|       |    }
-   79|      1|}
+   79|       |}

[richkadel]

Submitted that comment prematurely.

I'm putting more comments in #83257 because I think it's just as likely the MIRI changed the MIR that the coverage pass needs to generate coverage.

But it's not clear.

It's also from a doctest, which is something @Swatinem worked on in the last couple of months.

Maybe something changed affecting how doctest works.

[RalfJung]

The MIR pass produced from -Zinstrument-coverage did produce different results, on Windows.

Indeed, but my PR does not change rustc at all, so this cannot be caused by my PR.

[richkadel]

@tmiasko - The timing is very coincidental with your PR landing last night. Based on Ralf's last comment, I would expect other PRs to fail similarly. I don't know how your PR passed, or how this could be spurious, but it is suspect.

If we see more of these failures, you may need to look at reverting the PR. But I think we should make sure this is repeatable first.

@wesleywiser FYI

[tmiasko]

Timing indeed makes that PR suspect. That being said, I don't see how it could introduce any functional changes for builds without MIR inlining, like in this test case.

[richkadel]

Also, @RalfJung's PR succeeded on @bors retry.

Hard to understand how that could have happened, but for now let's assume it was a random and hopefully uncommon issue.