Skip to content

Refactor string_constraint_generatort #2695

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

Conversation

romainbrenguier
Copy link
Contributor

@romainbrenguier romainbrenguier commented Aug 7, 2018

The main goal is to extract all the add_axioms functions from the string_constraint_generatort class so that they can be reused from string_builtin_functiont classes. This has also the benefit of making the string_constraint_generatort class much smaller, and what is modified by these function is now clearer through their interface.
(warning: if you review commit by commit, the one before last is quite big)

Copy link
Collaborator

@martin-cs martin-cs left a comment

Choose a reason for hiding this comment

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

This PR seems to do what it describes. I don't have a clear enough picture of the design to say whether this is the right thing to do or not.

symbol_exprt fresh_univ_index(const irep_idt &prefix, const typet &type);

symbol_exprt fresh_exist_index(const irep_idt &prefix, const typet &type);

Copy link
Collaborator

Choose a reason for hiding this comment

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

From a formal point of view, having these being handled the same is a little concerning. I'm guessing this is just a naming artefact rather than something deeper.

@romainbrenguier romainbrenguier force-pushed the clean-up/string-constraint-generator branch 2 times, most recently from 3826266 to 50d4bd3 Compare August 8, 2018 13:23
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.

Approving of the changes to the README file. For everything else I have to trust that it's right (CI says it currently isn't).

@romainbrenguier romainbrenguier force-pushed the clean-up/string-constraint-generator branch from 50d4bd3 to 595e976 Compare August 8, 2018 17:15
@romainbrenguier romainbrenguier requested a review from allredj August 9, 2018 05:38
@romainbrenguier romainbrenguier force-pushed the clean-up/string-constraint-generator branch 2 times, most recently from 9e621eb to 1741c6e Compare August 9, 2018 10:04
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.

Looks good. Please see my question about having the string constraint functions returning the constraints. I don't really understand why and how we do that.

@@ -116,13 +116,6 @@ class string_constraint_generatort final
/// Set of strings that have been created by the generator
const std::set<array_string_exprt> &get_created_strings() const;

exprt get_witness_of(
Copy link
Contributor

Choose a reason for hiding this comment

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

Not sure extracting the witnesses is an improvement. What is the rationale behind that?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Conceptually it's a part of the solver procedure, and it's not part of the constraints. I want to make the distinction clear between what we are solving (string constraints) and how (string refinement).

exprt char2,
exprt char_a,
exprt char_A,
exprt char_Z)
Copy link
Contributor

Choose a reason for hiding this comment

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

These should all be const refs.

@@ -84,6 +76,15 @@ class array_poolt final
const typet &char_array_type);
};

array_string_exprt
find(array_poolt &array_pool, const refined_string_exprt &str);
Copy link
Contributor

Choose a reason for hiding this comment

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

array_pool should probably be const.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

A new entry is created if str was not already present, so the pool cannot be const

@@ -90,6 +90,18 @@ class array_poolt final
/// are given as a struct containing a length and pointer to an array.
array_string_exprt of_argument(array_poolt &array_pool, const exprt &arg);

/// Collection of constraints of different types: existential formulas,
/// universal formulas, and "not contains" (universal with one alternation).
struct string_constraintst final
Copy link
Contributor

Choose a reason for hiding this comment

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

The name choice is not great as it looks very much like string_constraintt and makes it fairly confusing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

agreed, any suggestion?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

string_constraint_sett?

Copy link
Contributor

@allredj allredj Aug 10, 2018

Choose a reason for hiding this comment

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

How painful would it be to keep this string_constraintst and rename string_constraintt to something else?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not very, but if we change we should try to make it a definitive choice.
I guess any choice in the regexp: (universal_ | quantified_)? (string | array) _ (property | formula | constraint) t could work

Copy link
Contributor

Choose a reason for hiding this comment

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

string_constraintt -> universal_string_constraintt would make sense to me.

return generator.add_axioms_for_concat_char(result, input, character);
auto pair = generator.add_axioms_for_concat_char(result, input, character);
pair.second.existential.push_back(equal_exprt(pair.first, return_code));
return pair.second;
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't understand what we're doing here, and that commit introduces a lot of code duplication. What exactly are we doing?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes this is a bit boilerplate, I will try to refactor that

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've added commits at the end (the "Move add_axioms_*" ones) which show how the constraints() codes should look like. I haven't done it for concat and insert yet because it requires getting rid of the other usages of these add_axioms functions first.

@romainbrenguier romainbrenguier force-pushed the clean-up/string-constraint-generator branch 2 times, most recently from bb54d77 to cdcb2b5 Compare August 10, 2018 09:13
@romainbrenguier romainbrenguier force-pushed the clean-up/string-constraint-generator branch 5 times, most recently from 1767acf to a097827 Compare August 29, 2018 10:28
These are not using private field of the class but only calling public
functions.
Since this is only updated when we do array_pool operations it makes
sense to move it there.
instead of generator.get_created_strings which does the same thing.
This is just an alias for the default behavior of fresh_symbol
This better seperates the object we are constructing from the tools we
are using to construct it and will make it easier to make constraint
generation functions static.
This make the role of these functions clearer.
This will be necessary to make the functions static
This makes how the functions interact with the generator clearer, and
make it easier to reuse the functions outside of the class and to unit
test them.
These methods are now non-member functions.
Some functions that were used for debugging have been remove from string
constraint generator.
We adapt to that by adding a vector tracking created symbols when the
DEBUG flag is active.
The constraints are now added directly by the string_builtin_function
objects, so the code can be moved there.
@romainbrenguier romainbrenguier force-pushed the clean-up/string-constraint-generator branch from cddfd18 to a6fe4e1 Compare September 10, 2018 08:42
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: a6fe4e1).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/84271237

@romainbrenguier romainbrenguier merged commit ec1844e into diffblue:develop Sep 10, 2018
@romainbrenguier romainbrenguier deleted the clean-up/string-constraint-generator branch September 10, 2018 13:00
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.

4 participants