Stream: t-compiler/wg-polonius

Topic: placeholder loans vs placeholder subsets

lqd (Mar 05 2020 at 23:09, on Zulip):

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 ?

lqd (Mar 05 2020 at 23:09, on Zulip):

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)

lqd (Mar 05 2020 at 23:10, on Zulip):

(and have also prototyped a location-insensitive variant like I mentioned yesterday, same similar ok-ish behaviour which needs full testing)

lqd (Mar 05 2020 at 23:11, on Zulip):

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 ?

lqd (Mar 05 2020 at 23:13, on Zulip):

that's the question I mentioned yesterday @nikomatsakis :point_up: :) (nothing urgent)

lqd (Mar 13 2020 at 17:45, on Zulip):

(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)

nikomatsakis (Mar 17 2020 at 21:40, on Zulip):

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.

lqd (Mar 17 2020 at 21:50, on Zulip):

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)

lqd (Mar 17 2020 at 21:53, on Zulip):

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 subset and requires ("contains") to take those new facts into account in their TC

lqd (Mar 17 2020 at 21:56, on Zulip):

(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)

lqd (Mar 17 2020 at 21:58, on Zulip):

that should work but rn it'll just move the OOMs from rustc fact gen to polonius move errors on these big tests

lqd (Mar 17 2020 at 22:00, on Zulip):

(which is more of a datafrog problem than a problem of move errors per se -- it's not made for gen-kill problems)

Last update: Jun 20 2021 at 00:15UTC