Drop flag statement creation depends on `FxHashMap` interation order

[Aaron1011]

This code creates MIR statements based on an FxHashMap iteration order:

rust/compiler/rustc_mir_transform/src/elaborate_drops.rs

Lines 493 to 495 in 404c847

	for flag in self.drop_flags.values() {
	self.patch.add_assign(loc, Place::from(*flag), false_.clone());
	}

drop_flags is defined as:

rust/compiler/rustc_mir_transform/src/elaborate_drops.rs

Line 260 in 404c847

drop_flags: FxHashMap<MovePathIndex, Local>,

Since FxHashMap's fixed seed is different between 32 and 64 bit platforms, we may end up creating statements in a different order on 32-bit vs 64-bit hosts (the target platform passed to the compiler has no effect).

We should probably sort by MovePathIndex before creating the statements.

[camelid]

Perhaps it should just use BTreeMap instead?

[apiraino]

Revisiting this issue to evaluate the priority.

@pnkfelix unsure about the status and global direction of this issue. Do we have some work in progress somewhere? I've tried following the breadcrumbs and landed on #102698. Unsure if it helps and - if yes - how much does that pull request covers to fix this issue.

opinions? thanks :)