-
Notifications
You must be signed in to change notification settings - Fork 273
Refactor/move abstract interpreter functionality into goto analyzer 1 #7120
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: develop
Are you sure you want to change the base?
Refactor/move abstract interpreter functionality into goto analyzer 1 #7120
Conversation
It is already supported, tested and documented so this is straight-forward. The biggest change is migrating and updating tests.
There is not much to do as this is already supported, tested and documented in goto-analyzer and there are no tests for this in goto-instrument.
The functionality is already present and tested so there is not much to do.
Codecov Report
@@ Coverage Diff @@
## develop #7120 +/- ##
===========================================
- Coverage 77.92% 77.87% -0.05%
===========================================
Files 1576 1576
Lines 181645 181643 -2
===========================================
- Hits 141541 141458 -83
- Misses 40104 40185 +81
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
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.
THANK YOU for this cleanup!!! Would you mind also updating the man page to reflect these changes?
The first part of moving functionality that is basically "run the abstract interpreter and then ..." from
goto-instrument
togoto-analyzer
. I'm doing this to remove duplication of functionality, add configurability (the options ongoto-analyzer
are not completely orthogonal but they are a lot better than at the moment), add testing and to try to slim downgoto-instrument
so that it is a bit more closer to it's original intent of performing goto-model to goto-model transformations. Please say if you disagree with this as a line of refactoring.This will also provide a more radical alternative than #7111 to resolving some of the issues with #7041.