Axiomatizing frame functions to be injective #543
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Carbon internally uses the functions
FrameFragment
andFrameCombine
both to frame functions and to model predicate snapshots, essentially equivalently to Silicon'sXToSnap
andSnapCombine
.However, currently, they are not axiomatized to be injective, even though they clearly could be.
Doing this has the advantage of giving us a way of framing heap information that's hidden inside predicates besides the existing known-folded-permission mechanism, which has the advantage of also working retroactively, fixing issues #355 and #259 and also #278.
The point is that during a predicate unfolding, Carbon emits an assumption like
(for a predicate
P
containing only a permission to fieldf
. IfFrameFragment
is known to be injective, this existing assumption suffices to get retroactive framing in cases like the ones shown in the issues.This PR introduces inverse functions for both of the aforementioned functions and axioms that mark the functions as injective using the inverse functions.