-
Notifications
You must be signed in to change notification settings - Fork 273
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
Remove deprecated Java and string options [TG-4282] #2907
Conversation
5a00bb8
to
2df4f4f
Compare
There was a problem hiding this 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).
src/cbmc/cbmc_parse_options.h
Outdated
@@ -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):" \ |
There was a problem hiding this comment.
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"?!
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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")); | ||
} |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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")); | ||
} |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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)
2df4f4f
to
d8e452d
Compare
There was a problem hiding this 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).
There was a problem hiding this 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).
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. |
@peterschrammel needs a rebase |
Actually @peterschrammel merge #2935 first since that causes test-gen test failures in any case |
997aa1e
to
dc94b85
Compare
There was a problem hiding this 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
dc94b85
to
56d01f4
Compare
There was a problem hiding this 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
@smowton, rebased. |
No description provided.