Skip to content

Document byte_update_exprt and rename non-const functions #4675

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

Merged

Conversation

romainbrenguier
Copy link
Contributor

In some cases the non-const version was unnecessarily called because it
has the same name as the const version.
This pull requests avoids that from happening in 9 cases for op, 2 for value and 3 for
offset.

  • 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).
  • [na] My commit message includes data points confirming performance improvements (if claimed).
  • My PR is restricted to a single feature or bugfix.
  • [na] White-space or formatting changes outside the feature-related changed lines are in commits of their own.

Copy link
Collaborator

@tautschnig tautschnig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Renaming functions without following an appropriate deprecation path is a no-go.

@romainbrenguier romainbrenguier force-pushed the refactor/byte_update_exprt branch 3 times, most recently from ce2a97a to 6fe7c1e Compare May 21, 2019 10:57
@romainbrenguier
Copy link
Contributor Author

@tautschnig

Renaming functions without following an appropriate deprecation path is a no-go.

I've now kept both versions and deprecated the old one.

Copy link
Collaborator

@tautschnig tautschnig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me - except I'd prefer if the set_* methods actually took an argument as discussed.

@@ -2057,20 +2057,22 @@ bool simplify_exprt::simplify_byte_extract(byte_extract_exprt &expr)

bool simplify_exprt::simplify_byte_update(byte_update_exprt &expr)
{
const byte_update_exprt &expr_const = as_const(expr);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this use of as_const actually necessary?

Documentation was missing
The documentation was missing.
In some cases the non-const version was unnecessarily called because it
has the same name as the const version.
We define accessor functions with a different name to make the
non-constantness explicit.
The non-const accessors which have the same name as the const one
shouldn't be used anymore to avoid confusion and unknowningly calling
the non-const version.
@romainbrenguier romainbrenguier force-pushed the refactor/byte_update_exprt branch from 6fe7c1e to 15e9d8c Compare May 22, 2019 14:44
The non-const version shouldn't be used anymore when we don't actually
need to modify the operands.
@romainbrenguier romainbrenguier force-pushed the refactor/byte_update_exprt branch from 15e9d8c to 635ad8b Compare May 22, 2019 14:59
@tautschnig tautschnig merged commit 766b031 into diffblue:develop May 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants