-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
subset errors #153
Comments
Design we landed onWe ultimately landed on using the Approach A, as described here. First, the compiler produces the following input sets for polonius:
To optimize the naive rules using the outputs from the LI analysis, however, we can limit
|
Location insensitive (LI)The location insensitive analysis as currently specified doesn't compute the transitive
then we can compute errors using This yields the following results:
|
Naive, plus Naive optimized with Location Insensitive resultsThe naive analysis can be implemented using the rule originally given. But we can also optimize the naive analysis based on the LI results:
|
OptimizedThe "optimized" analysis avoids computing the transitive subset and contains relationships in full. Instead, it computes them only when necessary. In particular, when an origin goes dead, it will remove that origin, but also compute the transitive closure of subset relations and things that origin may have been involved in, so that if you have This works out well for illegal access errors: for that purpose, we only care which loans are live, we don't care which origin they are found in. So we don't need to know those full sets. Also, this can be optimized using LI results in the same fashion as naive. However, for subset errors, this is a problem. We can't just lean on the Therefore, we choose to build up a separate, transitive relation that propagates placeholder origins forward:
For efficiency, this relation can be filtered as well. We only need to consider the placeholder origins in |
So @lqd and I had a big discussion today and resolved the major open questions with respect to reporting "subset errors". In short, we decided to adopt the approach laid out in the original smallcultfollowing blog post, but with a bunch of other details. =) This issue tracks the implementation of that work and explains the rationale.
The problem
Rust functions contain "placeholder origins" like
'a
and'b
in this example:We want this code to be an error. But the error is not due to an illegal access error -- it is because data with the origin
'a
is returned with the origin'b
, and there is no'a: 'b
where clause.Alternative A: Use subsets and declare errors
The original blog post proposed an approach to solving this problem where we looking for a subst relation
subset('a, 'b, _)
that involves two placeholder origins'a
and'b
, and then compare that against a set of "known subsets" (derived from the where clauses). If we find a subset relation that is not known to be valid, that's an error. This can (ultra naively) be expressed with a single rule:Alternative B
The main competitor that we were considering was the idea of using 'placeholder loans'. In this approach, for each placeholder origin, we have a corresponding placeholder loan. We can then compute the
subset
andcontains
relations as normal, and declare an error if a placeholder loan finds its way into a placeholder origin where it doesn't belong (i.e., in the above example, the placeholder origin for'b
would contain the loan for'a
). So the error rule would like something like this:but we also need some rules like
Consideration: Elegance
Naturally we want to find relatively minimal rules that are clean and easy to understand. The subset approach largely wins on this approach, but as we'll see later there are a few complications.
Consideration: Origins are just sets of loans, right?
One of the original motivations for pursuing the "placeholder loan" approach was that we wanted to be able to treat origins as if they were just sets of loans and didn't have an identity of their own. However, in practice, we can't quite do this anyway, because we have to track
subset
relations forward through the graph (see #107 for related discussion about that). So it seems like either way origins have some identity of their own in the polonius framework.Consideration: Location Insensitive analysis
One of the things we were considering is the ability to optimize the naive and optimized analysis based on a preliminary location insensitive run. This location insensitive run will produce results that can be used to limit the transitive closure computations and make everything more performant.
The text was updated successfully, but these errors were encountered: