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

[Do not review just yet] Cleanup exprt and expr_util #8451

Draft
wants to merge 11 commits into
base: develop
Choose a base branch
from

Conversation

tautschnig
Copy link
Collaborator

This PR combines a series of changes that will mostly become PRs of their own.

  • Each commit message has a non-empty body, explaining why the change was made.
  • Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
  • The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
  • Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
  • My commit message includes data points confirming performance improvements (if claimed).
  • My PR is restricted to a single feature or bugfix.
  • White-space or formatting changes outside the feature-related changed lines are in commits of their own.

Cleaning of &&/|| introduced `GOTO` and `SKIP` instructions without a
source location.
Removes one of the functions from the expr_util translation unit that is
supposed to be deprecated.
Avoids use of the now-deprecated exprt methods.
The value representation is an implementation detail. Callers should use
methods at a higher level of abstraction.
This will eventually replace `make_boolean_expr` to remove one of the
functions from the expr_util translation unit, which is supposed to be
deprecated.
When the operand can be a Boolean constant we can don't need to wait for
simplify_exprt to clean up the avoidable not_exprt.
`make_and` does not necessarily produce an `and_exprt`, so its name is
misleading. We already have `conjunction(exprt::operandst)`, and will
now have a variant thereof that takes exactly two operands.
We did not consistently use it, and the three methods that did so can
easily be adjusted to match the remaining ones in directly taking
`exprt` instead.
This will eventually remove one of the functions from the expr_util
translation unit, which is supposed to be deprecated.
This is no longer used and can easily be avoided by constructing a
fixedbvt from an integer.
Use constructor chaining to avoid code duplication and remove the unused
operator==(int).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant