Skip to content

Remove deprecated Java and string options [TG-4282] #2907

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

peterschrammel
Copy link
Member

No description provided.

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.

This PR failed Diffblue compatibility checks (cbmc commit: 2df4f4f).
Status will be re-evaluated on next push.
Please contact @peterschrammel, @thk123, or @allredj for support.

Common spurious failures:

  • the cbmc commit has disappeared in the mean time (e.g. in a force-push)
  • the author is not in the list of contributors (e.g. first-time contributors).

@@ -50,8 +50,6 @@ class optionst;
"(dimacs)(refine)(max-node-refinement):(refine-arrays)(refine-arithmetic)"\
"(refine-strings)" \
"(string-printable)" \
"(string-max-length):" \
"(string-max-input-length):" \
Copy link
Collaborator

Choose a reason for hiding this comment

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

CBMC seems to be missing "--max-nondet-string-length"?!

Copy link
Member Author

Choose a reason for hiding this comment

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

This option is not required for CBMC at the moment as the string solver integration for C is incomplete.

Copy link
Collaborator

Choose a reason for hiding this comment

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

That I am aware of, but we do have (refine-strings) etc. So really we should not have a half-consistent view. I believe the way to go about this is as we have done with several other option sets already: define the set of options and the help strings in a header file and just use the macro.

Copy link
Member Author

Choose a reason for hiding this comment

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

Fully agreed. Note, however, that refine-strings is default in JBMC and hence the options won't be the same for CBMC and JBMC.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ok, so we might need two different sets, but it would still be nice to have all this encapsulated in some header file. It's fairly easy to fix now, but will be a lot more costly later on.

{
object_factory_parameters.max_nondet_array_length =
safe_string2size_t(cmd.get_value("java-max-input-array-length"));
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

The code below this one (if(cmd.isset("max-nondet-array-length"))) needs to be removed as well: it's the front-end that now does it, and it will provide the result in the parameters. This, in turn, would hopefully enable a larger cleanup in that cmd should no longer be necessary in here?

Copy link
Member Author

@peterschrammel peterschrammel Sep 6, 2018

Choose a reason for hiding this comment

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

The code below this one (if(cmd.isset("max-nondet-array-length"))) needs to be removed as well: it's the front-end that now does it, and it will provide the result in the parameters.

No, this has been a long time hack. The front end is and has been doing that in addition to the language module. Avoiding that would require options to be fed into the language module, which is a separate refactoring (and will eventually become obsolete with Daniel's ambitions to get rid of languaget).

Copy link
Collaborator

@tautschnig tautschnig Sep 6, 2018

Choose a reason for hiding this comment

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

But why do we need to keep doing it in addition in here? I don't see how the options story applies here: it's all being passed via object_factory_parameters already?

Copy link
Member Author

Choose a reason for hiding this comment

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

The same options are both used by the languaget instance and in goto passes.
The object_factory_parameters in parse_options is only used in goto passes. The languaget instance does its own parsing.

Copy link
Member Author

@peterschrammel peterschrammel Sep 6, 2018

Choose a reason for hiding this comment

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

One could either retrieve the object_factory_parameters from a (temporary) languaget instance or pass options into the languaget instance (preferred).

Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't have a sufficient grasp of the Java front-end to tell what the correct solution is, but surely parsing the same command-line option multiple times is not acceptable.

Copy link
Member Author

Choose a reason for hiding this comment

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

This will definitely require a solution as we will face the same issue when generalising/porting the object_factory to C. And we won't be able to wait until we got rid of languaget in this case. (I'm still remembering the incident with #2192, #2157 which still hasn't been resolved after 4 months).

Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm happy to dismiss my blocking review on this one if the problem cannot be solved right here. I just want to make sure it does get resolved eventually, with first steps defined. The large-scale refactorings surely aren't the solution...

Copy link
Member Author

Choose a reason for hiding this comment

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

Noted here: #2908

{
object_factory_parameters.max_nondet_tree_depth =
safe_string2size_t(cmd.get_value("java-max-input-tree-depth"));
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

Equally, if(cmd.isset("max-nondet-tree-depth")) needs to go away as well. The front-end does the command-line options parsing, not the language processing code.

^VERIFICATION SUCCESSFUL$
^EXIT=0$
^SIGNAL=0$
--
--
This doesn't work under symex-driven lazy loading because it is incompatible with --lazy-methods
This doesn't work under symex-driven lazy loading because it is incompatible with lazy-methods
Copy link
Collaborator

Choose a reason for hiding this comment

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

There's some incomplete work here - it seems just -- has been removed in this line? Also, the test is explicitly named test_lazy.

^EXIT=0$
^SIGNAL=0$
elaborate java::A\.f:\(\)V
--
elaborate java::B\.g:\(\)V
--
This doesn't work under symex-driven lazy loading because it is incompatible with --lazy-methods
This doesn't work under symex-driven lazy loading because it is incompatible with
Copy link
Collaborator

Choose a reason for hiding this comment

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

Incompatible with ... what? (multiple occurrences)

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.

This PR failed Diffblue compatibility checks (cbmc commit: d8e452d).
Status will be re-evaluated on next push.
Please contact @peterschrammel, @thk123, or @allredj for support.

Common spurious failures:

  • the cbmc commit has disappeared in the mean time (e.g. in a force-push)
  • the author is not in the list of contributors (e.g. first-time contributors).

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.

This PR failed Diffblue compatibility checks (cbmc commit: 997aa1e).
Status will be re-evaluated on next push.
Please contact @peterschrammel, @thk123, or @allredj for support.

Common spurious failures:

  • the cbmc commit has disappeared in the mean time (e.g. in a force-push)
  • the author is not in the list of contributors (e.g. first-time contributors).

@peterschrammel peterschrammel changed the title Remove deprecated Java and string options Remove deprecated Java and string options [TG-4282] Sep 11, 2018
@smowton
Copy link
Contributor

smowton commented Sep 12, 2018

Since you assign me, and I'm idle due to just having come back from holiday, created https://github.com/diffblue/test-gen/tree/bump/2907 removing use of deprecated parameters and #2942 fixing a silly exposed bug.

@smowton
Copy link
Contributor

smowton commented Sep 12, 2018

@peterschrammel needs a rebase

@smowton
Copy link
Contributor

smowton commented Sep 12, 2018

Actually @peterschrammel merge #2935 first since that causes test-gen test failures in any case

@peterschrammel peterschrammel force-pushed the remove-deprecated-options branch from 997aa1e to dc94b85 Compare September 14, 2018 09:47
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: dc94b85).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/84816090

@peterschrammel peterschrammel force-pushed the remove-deprecated-options branch from dc94b85 to 56d01f4 Compare September 14, 2018 11:10
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: 56d01f4).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/84820717

@peterschrammel
Copy link
Member Author

@smowton, rebased.

@peterschrammel peterschrammel merged commit d54d101 into diffblue:develop Sep 14, 2018
@peterschrammel peterschrammel deleted the remove-deprecated-options branch September 14, 2018 21:24
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.

7 participants