-
Notifications
You must be signed in to change notification settings - Fork 26
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
Generate triggers more conservatively #708
Conversation
…ate triggers if subset of operators is used where we know a trigger is valid or invalid. Do not generate triggers if operators are in neither of the valid/invalid sets.
…and disallowed (integer minus) in triggers.
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.
If you take a look at any excessive warnings of triggers not generated this looks good!
SonarCloud Quality Gate failed. |
There are some files that still have quite a few trigger warnings (kadane.java, set comprehension code generation, KeYAbruptTerminationChallenge.java, basic-examples.c, kernel-example-v3.pvl, forkjoininforloop.pvl, and max-sort.pvl), but these can be resolved in a new PR by actually adding the proper triggers. Some other files also have trigger warnings, but in those cases a trigger is not actually possible (i.e. (\forall int tid; f(tid - 1)). |
This PR ensures that triggers are only generated for expressions that use a subset of operators. For this subset of operators it is known for each operator if it is allowed to appear in a trigger or not. For example, + is not allowed in a trigger, but sequence size (
|xs|
) is. If an operator is encountered that is not included in this subset, no trigger is generated for the nearest enclosing forall.This PR also includes a fix for including tuple notation in the syntax, which was also needed for Han's thesis.