Port of changes to test-gen-support to master (1) #1123
Conversation
to_ulong() will negate a negative number, rather than returning its two's complement representation as an unsigned type as we might reasonably suppose. Instead use to_long() everywhere to preserve the bitwise representation and then use sign-bit filling to make sure the value is correctly re-encoded as mp_integer.
This code was originally in the `dump_ct` class but it is useful in other places (specifically when generating stubs we don't want to include any of these).
The existing symbols were missing a few symbols from the files they were supposed to be symbols for. Further, for some reason the math functions were sometimes used with a double underscore prefix. Some included files were missed (fenv.h, errno.c, noop.c). There were some other prefixes that clearly have internal meaning (__VERIFIER, nondet_). Also asserts weren't being included. These problems were discovered by running the make and seeing which tests failed and what functions were being stubbed. It is therefore not necessarily exhaustive. Perhaps there is a better approach to this problem.
See documentation in scripts/bash-autocomplete/Readme.md
tautschnig
requested review from
peterschrammel,
smowton,
thk123,
forejtv,
mgudemann and
cristina-david
|
@tautschnig, just to make sure what is the intention behind these PRs is: Are they to discuss which commits should be selected for backporting or do you want to do a |
|
@peterschrammel In absence for an answer on #1121 I have no idea what the plans of the DiffBlue team on this are. The bare minimum I'd want is all the Java front-end fixes to get merged back into master. I wouldn't necessarily mind a full merge, but I suppose some patches require further discussion. So until I know about plans I'm hoping to enable such a discussion and possible full review. |
|
I'm definitely in favour of getting as much as possible into master. The necessity of having a test-gen-support branch arose mainly due to the need for bypassing the inertia of the master branch. |
|
Yes, I fully understand, and it's great to have your support on this. I'll just try to contribute my share to make a merge a bit more likely... For this particular pull request: if everyone can just review the commits attributed to them, this might be of help. (There is a major risk of mis-merges here, and quite a lot has changed, e.g., doxygen comments are now to-be-done.) |
|
Would it help if I classified the commits as "useful (should definitely be ported) / possibly useful (can do without) / not useful / discussion required" to support decisions on which commits to port? |
|
What I am worried about is that we'll get into a state where it gets very difficult to figure out what exactly the difference -- in terms of commits -- is between master and test-gen-support. If test-gen-support were to use a rebase strategy rather than merge the list of commits would always be trivial to obtain, and selectively merging individual commits into master would be fairly straightforward. Given the chosen merge strategy, picking individual commits while omitting others will make merges even harder when as more gets merged into master. Hence, e.g., annotations of #1121 might be good to have - but I'm not sure it's actually helpful? |
|
Rebasing the branch is not an option because it is used as a submodule in other repositories. We need a stable commit history for our cross-repository versioning. |
I don't see why submodules would rule out rebasing - submodules point towards a particular commit, and rebasing will alter various commit ids. As such the original commit ids remain stable as long as they don't get garbage collected. But then you'll have designed this carefully and with lots more information than I have. Anyway it seems any rebasing effort of mine (which this and all the subsequent pull requests amount to) is thus going to be continuously thwarted. It's probably time to move on. |
|
On each rebase we would have the preserve the old branch in order to reliably prevent the commits from being garbage collected. |
|
I believe the usual approach is to keep a "staging" or "next" branch and then switch over to this one such that the previous version is no longer needed. But you may have some set up where various previous versions are still in use, in which case you would indeed need to keep branches every time. I'll spend today attempting to rebase the full branch. If I can't get it done in that time frame I'll just copy over the current state of selected files and create a pull request that is devoid of all original author information, unfortunately. Any advice on a better strategy is much appreciated. |
This is the intended equivalent of #579. It would likely make sense to split this into a set of pull requests, but originally it had been merged as a single step ...