Skip to content

new constructor for function_application_exprt #4317

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
merged 1 commit into from
Mar 4, 2019

Conversation

kroening
Copy link
Member

@kroening kroening commented Mar 3, 2019

The new constructor

  1. moves the arguments
  2. enforces the type of the function to be mathematical_function
  3. automatically sets the type of the application to be the codomain of the
    function.
  4. checks that the right number of arguments is given.

Note that the function symbol can't be moved during construction as its type
is needed.

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

The new constructor
1) moves the arguments
2) enforces the type of the function to be mathematical_function
3) automatically sets the type of the application to be the codomain of the
function.
4) checks that the right number of arguments is given.

Note that the function symbol can't be moved during construction as its type
is needed.  The types of the arguments are not checked.
Copy link
Contributor

@allredj allredj left a comment

Choose a reason for hiding this comment

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

✔️
Passed Diffblue compatibility checks (cbmc commit: 493324d).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/102948379

: binary_exprt(
_function,
ID_function_application,
multi_ary_exprt(irep_idt(), std::move(_arguments), typet()),
Copy link
Collaborator

Choose a reason for hiding this comment

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

This looks very odd. Can we use ID_arguments? exprt{ID_arguments, std::move(_arguments)} would IMHO look cleaner. (But that's probably not possible until #3502 is merged.)

Copy link
Member Author

Choose a reason for hiding this comment

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

Sure, could use ID_arguments, but could also contemplate something like ID_tuple (which is what is happening here).

Copy link
Member Author

Choose a reason for hiding this comment

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

(Either should be a separate PR, and would need to change all constructors).

@kroening kroening merged commit 91a0307 into develop Mar 4, 2019
@tautschnig tautschnig deleted the mathematical_functions branch March 4, 2019 11:28
kroening pushed a commit that referenced this pull request Mar 4, 2019
This is follow-up from PR #4317.

This introduces tuple_exprt.

function_application_exprt now uses tuple_exprt for the argument operand,
instead of an expression with empty ID.
@kroening kroening mentioned this pull request Mar 4, 2019
4 tasks
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.

3 participants