-
Notifications
You must be signed in to change notification settings - Fork 152
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
Add raw term production #3829
Add raw term production #3829
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am confused by this. What exactly is going on here?
runtimeverification/llvm-backend#904 is the surrounding context; this isn't quite ready for a review yet. Open to suggestions for alternative implementations! |
Closing after discussing with @dwightguth; a better solution is to have the backend insert a symbol automatically as a preprocessing step. |
This is an alternative formulation to runtimeverification/k#3829; that PR contains the original context for why this change is necessary. Rather than adding a regular symbol to the K standard library source and using a check in the frontend to ensure that user code doesn't mention it, we directly emit a symbol into each definition with a name that the frontend cannot reference. We also bump the version number for the proof hint format so that this non-standard symbol must be explicitly accepted by the Python client code.
The LLVM backend code that emits binary KORE terms into a proof trace wraps terms that are not represented as symbols at runtime in an injection into
KItem
to allow them to be serialized using the code-generated recursion scheme used elsewhere in the backend.However, doing so is not sound (see runtimeverification/llvm-backend#904 for the full context). The additional injection changes the semantics of the serialized terms, and it is ambiguous whether client parser code should strip the injection from terms it reads from the trace.
The solution to this problem that I propose in this PR is to add a symbol to the K standard library whose only purpose is to signal "the term under this symbol is an injection into
KItem
that should be stripped when parsing a trace"; I have also implemented a small check that verifies user code does not attempt to write rules using this symbol.Subsequent follow-up changes will be required to fully implement this solution:
#rawTerm
instead of injections, along with a version bump for the format.There may be a better way to implement something equivalent to these changes; I'm open to suggestions!