Skip to content
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

Axiomatizing frame functions to be injective #543

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

marcoeilers
Copy link
Contributor

@marcoeilers marcoeilers commented Dec 28, 2024

Carbon internally uses the functions FrameFragment and FrameCombine both to frame functions and to model predicate snapshots, essentially equivalently to Silicon's XToSnap and SnapCombine.
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

assume UnfoldingHeap[null, P(x)] == FrameFragment(UnfoldingHeap[x, f]);

(for a predicate P containing only a permission to field f. If FrameFragment 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.

@marcoeilers marcoeilers requested a review from Dev-XYS January 8, 2025 15:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant