rustc_mir_transform: Make DestinationPropagation stable for queries

[Enselic]

By using FxIndexMap instead of FxHashMap, so that the order of visiting of locals is deterministic.

We also need to bless
copy_propagation_arg.foo.DestinationPropagation.panic*.diff. Do not review the diff of the diff. Instead look at the diff files before and after this commit. Both before and after this commit, 3 statements are replaced with nop. It's just that due to change in ordering, different statements are replaced. But the net result is the same. In other words, compare this diff (before fix):

• https://github.com/rust-lang/rust/blob/090d5eac722000906cc00d991f2bf052b0e388c3/tests/mir-opt/dest-prop/copy_propagation_arg.foo.DestinationPropagation.panic-unwind.diff

With this diff (after fix):

• https://github.com/rust-lang/rust/blob/f603babd63a607e155609dc0277806e559626ea0/tests/mir-opt/dest-prop/copy_propagation_arg.foo.DestinationPropagation.panic-unwind.diff

and you can see that both before and after the fix, we replace 3 statements with nops.

I find it slightly surprising that the test this PR affects did not previously fail spuriously due to the indeterminism of FxHashMap, but I guess in can be explained with the predictability of small FxHashMaps with usize (Local) keys, or something along those lines.

This should fix this comment, but I wanted to make a separate PR for this fix for a simpler development and review process.

Part of #84447 which is E-help-wanted.

r? @cjgillot who is reviewer for the highly related PR #119252.

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[cjgillot]

Thanks.
@bors r+

[bors]

📌 Commit f603bab has been approved by cjgillot

It is now in the queue for this repository.

[bors]

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

[Enselic]

@cjgillot Friendly ping to re-approve. There were only conflicts in use declarations. The diff after rebase from what you already approved can most easily be seen with git range-diff:

$ git range-diff f603bab^..f603bab 95eb5bc^..95eb5bc
1:  f603babd63a ! 1:  95eb5bcb67b rustc_mir_transform: Make DestinationPropagation stable for queries
    @@ compiler/rustc_mir_transform/src/dest_prop.rs

     -use std::collections::hash_map::{Entry, OccupiedEntry};
     -
    - use crate::simplify::remove_dead_blocks;
      use crate::MirPass;
     -use rustc_data_structures::fx::FxHashMap;
     +use rustc_data_structures::fx::{FxIndexMap, IndexEntry, IndexOccupiedEntry};

The proper interpretation of that output is: "the only difference between the diff of the approved commit and the diff of the rebased commit is that the line use crate::simplify::remove_dead_blocks; was removed". Which makes sense since that line was removed on master by an unrelated commit (namely this).

[tmiasko]

@bors r=cjgillot

[bors]

📌 Commit 95eb5bc has been approved by cjgillot

It is now in the queue for this repository.

[bjorn3]

I find it slightly surprising that the test this PR affects did not previously fail spuriously due to the indeterminism of FxHashMap

FxHashMap is actually deterministic given the same HashMap implementation. FxHasher doesn't use randomness unlike the default HashMap hasher (RandomState).