NLL: diagnostics deviate from source line order for no obvious reason

[pnkfelix]

Consider:

https://github.com/rust-lang/rust/blob/master/src/test/ui/span/send-is-not-static-ensures-scoping.nll.stderr

compare it to the AST borrowck output:

https://github.com/rust-lang/rust/blob/master/src/test/ui/span/send-is-not-static-ensures-scoping.stderr

1. Why are we inverting the order in which we report these diagnostics?
2. We may want to consider not doing that. Even if it means e.g. buffering the diangotics and sorting them before emitting them, or some similar hack. (I admit I am loathe to do this since I myself really like when I am able to correlate the RUST_LOG output with diagnostic output. But if necessary, we could add a -Z flag to turn off the buffer+sorting, in order to bring back such correlation. For end users, buffering+sorting is probably a net win.)

An important reason to prioritize this: Fixing this is likely going to make our internal process for comparing the diagnostic output more efficient.

[nikomatsakis]

Marking as Edition Preview 2 because .. maybe an easy fix.

[nikomatsakis]

I think we should just try visiting the basic blocks in reverse-postfix order. The visit occurs here:

rust/src/librustc_mir/dataflow/mod.rs

Lines 334 to 340 in 860d169

	fn analyze_results(&mut self, flow_uninit: &mut Self::FlowState) {
	let flow = flow_uninit;
	for bb in self.mir().basic_blocks().indices() {
	flow.reset_to_entry_of(bb);
	self.process_basic_block(bb, flow);
	}
	}

and in particular the for loop here goes over the basic blocks in an arbitrary order

rust/src/librustc_mir/dataflow/mod.rs

Line 336 in 860d169

for bb in self.mir().basic_blocks().indices() {

What we want to do is to go over in reverse post-order, which basically maps to execution order as we would normally define it. There is a function reverse_postorder that already exists to compute this ordering -- it returns an Iterator<Item = BasicBlock> -- and you can see some other random code that uses it here:

rust/src/librustc_mir/transform/qualify_consts.rs

Line 130 in 860d169

let mut rpo = traversal::reverse_postorder(mir);

So we basically want to change that code to iterate over the result of reverse_postorder.

[nikomatsakis]

OK, @csmoe did the RPO trick -- it definitely helped, but it doesn't seem to have fixed @pnkfelix's example. Not sure @pnkfelix how many more such examples there are -- however, it occurs to me -- @spastorino is also adding some buffering that we might use to do sorting after the fact, as well.

[nikomatsakis]

Assigning to @spastorino as this should get fixed as a side-effect of #46908

[spastorino]

Assigning to @pnkfelix as he took over the migrate thing. I can help here if needed at some point.

[pnkfelix]

@nikomatsakis do you think this should remain on EP2, or should we move it to RC?

(I'm going to take a shot at resolving it today, or at least doing as much as I can via the buffering we added. But still, time is tight for EP2.)

[pnkfelix]

moving this to RC as I think it is sufficiently low priority that it should not block EP2 nor NLL's release in EP2.