Description
As part of #40746, we need to migrate the region-maps into incremental. However, @cramertj's first effort (#40873) revealed that this is a bit more complicated than I thought at first. In particular the current regions are "whole-crate", but moving them to on-demand then introduces unacceptable dependency edges everywhere.
I think the overall structure that we want is that one does not request the "region maps" for the entire crate, but rather for a particular function or item (probably a body, though currently closures would share a region maps with their containing function).
This is made somewhat more complex by the fact that the RegionMaps construction code is quite old and a bit complex. It has for example a whole bunch of ref-cells that I think are primarily just an artifact of it being old -- i.e., the mutations should all be occuring during the construction phase, and not later.
Another complicating factor is the fact that we intern code extents to a small integer. Currently this interning is done globally (i.e., across all functions). I think it'd be fine, however, to do that locally (i.e., have a distinct vector for each function).
Each of the above complications can be refactored away -- probably! -- but it'll be non-trivial. It certainly makes sense to do this in phases. I'm not sure what those phases ought to be. Probably this:
- Purge the refcells -- use
&mutborrows duringmiddle::region::resolve_crate()and otherwise the data should be immutable. If this fails, we should figure out why and refactor accordingly. - Once the refcells are gone, try to thread through an appropriate fn or body-id into every call, and restructure the data to be per-fn.
- Once that is done, we can actually break the region map structure to be built "on demand" and do the construction per function.