Use DataflowResultsCursor instead of FlowAtLocation

[tmandry]

#61922 introduced DataflowResultsCursor, which provides a stateful caching interface atop FlowAtLocation.

It would be better to use DataflowResultsCursor from more places, both because it's a more convenient / less error-prone interface, and because it's best to have more than one code path exercising the same code. It's also awkward trying to support both interfaces at once (the cursor implementation would be cleaner if we didn't have to).

The main drawback to using it is that there will be extra state/branching in places where we don't need it.

cc @eddyb who asked me to open this, and (along with @nikomatsakis) helped provide inspiration for DataflowResultsCursor
cc @ecstatic-morse @pnkfelix

[ecstatic-morse]

There's a few places in librustc_mir which implement the same functionality:

• state_for_location
• DataflowResultsConsumer/FlowAtLocation
• DataflowResultsCursor (the latest and greatest)
• rustc_peek although it only considers the transfer function at assignment statements. I believe that this is merely an (unnecessary) optimization; it could easily be rewritten to use a cursor instead.

state_for_location can also be replaced easily. However, DataflowResultsConsumer is a bit more complex because it allows results to be zipped together (this is the purpose of FlowsAtLocation, although it claims to be for "cartesian products"). We could either rewrite all the consumers of this API to use the cursor API, or make DataflowResultsCursor the underlying implementation of DataflowResultsConsumer like so:

trait DataflowResultsVisitorEngine<'a> {
    type State: 'a;
    fn reset_to_start_of_block(&'a mut self, block: BasicBlock);
    fn seek(&'a mut self, loc: Location);
    fn get(&'a self) -> Self::State;
}

// Tuples of `DataflowResultsCursor`s can implement `DataflowResultsVisitorEngine`
impl<'a, A, B> DataflowResultsVisitorEngine<'a> for (DataflowResultsCursor<A>, DataflowResultsCursor<B>) {
    type State = (&'a BitSet<A::Idx>, &'a BitSet<B::Idx>);
    /* ... */
}

// New version of `DataflowResultsConsumer`
trait DataflowResultsVisitor<'a, 'tcx> {
      type Engine: DataflowResultsVisitorEngine<'a>;

    // Observation Hooks: override (at least one of) these to get analysis feedback.
    fn visit_block_entry(&mut self,
                         _bb: BasicBlock,
                         _flow_state: Self::Engine::State) {}

    fn visit_statement_entry(&mut self,
                             _loc: Location,
                             _stmt: &Statement<'tcx>,
                             _flow_state: Self::Engine::State) {}

    fn visit_terminator_entry(&mut self,
                              _loc: Location,
                              _term: &Terminator<'tcx>,
                              _flow_state: Self::Engine::State) {}

    fn visit(&mut self, cursor: &'a mut Self::Engine) {
         todo!()
    }
}

DataflowResultsVisitorEngine is basically a streaming iterator with a few extra methods. You could almost do this with a generic StreamingIterator trait with a zip method, but that means StreamingIterator::next would have to visit statements, terminators, and the start of a block.

[jonas-schievink]

Seems like this is done, right?

[ecstatic-morse]

Resolved by #69644.