does anyone remember if we explained somewhere why we felt placeholder loans were the way to go for subset errors, rather than say solution number 2 (tracking subsets of placeholder origins) which seems NLL-like (and solution 1 required the full subset TC which was not always applicable) ? was it because it felt like a natural representation ?
they don't work as-is in the optimized variant while I feel we expected they would (but I haven't investigated why tbh, they may be adapted to do so) while I've prototyped the other solution there and it seems to work in our limited tests (but I haven't tried in rustc's tests)
(and have also prototyped a location-insensitive variant like I mentioned yesterday, same similar ok-ish behaviour which needs full testing)
so before spending more time in that direction, I was wondering whether those 2 solutions maybe had obvious flaws/strengths which made us choose one over the other ?
that's the question I mentioned yesterday @nikomatsakis :point_up: :) (nothing urgent)
(note: I went with it anyway, and have reimplemented subset errors, in the LocationInsensitive/Hybrid and DatafrogOpt variants, and prototyped for fun the same kind of filtering to avoid tracking origins which can't cause subset errors, etc -- "for fun" because it can't exactly be applied to the other thing I was working on which was block-based transport)
I think I leaned towards placeholder loans, @lqd, because I wanted origins to be "equivalent" to some set of loans. This makes the connection to a type system like oxide more apparent. But I do remember that indeed the formulation of rules that tracked relations between origins was somewhat simpler.
it also avoids the problem of things that exist everywhere in the cfg and are propagated through it (even though it doesn't really come up in the rules but as duplicate derived facts which are then de-duped)
that being said, I was working on the OOMs caused by the Locations::All "hack which is not a hack", and for that I was thinking about representing these facts in a
outlives_everywhere relation, and modify the
requires ("contains") to take those new facts into account in their TC
(to avoid materializing the exact same facts as
outlives tuples over the whole cfg; this would only materialize where origins/loans would need to flow into another origin)
that should work but rn it'll just move the OOMs from rustc fact gen to polonius move errors on these big tests
(which is more of a datafrog problem than a problem of move errors per se -- it's not made for gen-kill problems)