-
Notifications
You must be signed in to change notification settings - Fork 11.4k
[move-abstract-interpreter] Make move-abstract-interpreter more general #21574
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
base: main
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
2 Skipped Deployments
|
type State: AbstractDomain; | ||
type Error; | ||
fn start(&mut self) -> Result<(), Self::Error>; | ||
fn join( |
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 suspect that for fancier (non bytecode verifier) analyses, we are going to need fn widen(&mut self, pre: &mut Self::State, post: &Self::State)
(or similar) as well. But I hesitate to change the abstract interpretation code for the verified to support this--wonder if we just want a copy.
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.
It is a good callout, and I think it is worth adding once we need it. For now though I hesitate mostly around adding it just in that we don't really know what shape it will take.
In other words, if we had a pass that we wanted to implement with widening, it would help inform the API a lot
Description
Test plan
Release notes
Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.
For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.