Skip to content

Cleanup of throws and asserts of goto_convert.cpp #2905

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 5 commits into from
Sep 27, 2018

Conversation

NlightNFotis
Copy link
Contributor

@NlightNFotis NlightNFotis commented Sep 5, 2018

In the same spirit as #2904 I am taking over development of #2814 because the original repository is now defunct, and I can't go further with that PR. This PR will host further development of that line of work.

  • Each commit message has a non-empty body, explaining why the change was made.
  • My contribution is formatted in line with CODING_STANDARD.md.
  • [n/a] Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
  • 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.
  • White-space or formatting changes outside the feature-related changed lines are in commits of their own.

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.

At the current state: please see #2814 for a number of blocking request.

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: a6c1699).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/85897734
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.

Passed Diffblue compatibility checks (cbmc commit: 3e57a9c).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/85899011

Remove duplicate invariants, and change some to transfer (cast)
function calls, which provide guarantees about the data types
by construction. Also substitute invariants with exceptions
where appropriate.
@NlightNFotis
Copy link
Contributor Author

@tautschnig This should be now in a state where it's ready for a review. Just a note:

I have tried my best to make the commits as close as possible to the contribution guidelines. It's a little bit hairy, because 3 people have worked on this thus far, and one of them is no longer with us, but we have to be careful not to lose commit information and attribution information, hence why the commits are the way they are and I can not squash them better.

@@ -0,0 +1,8 @@
CORE gcc-only
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why is this gcc-only?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You're right, this is a mistake, both clang and gcc report the same error.

CORE
main.c

^EXIT=134$
Copy link
Collaborator

Choose a reason for hiding this comment

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

Huh? That's not what should be happening...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What should be happening? I see that gcc and clang produce warnings that the range is empty, but are happy to compile nonetheless. Should I remove the invariant?

Copy link
Collaborator

Choose a reason for hiding this comment

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

We should be able to support whatever GCC and Clang do. 134 (a failing invariant) is not an exit code we should ever be producing for a syntactically valid C program.


throw 0;
}
bool res = get_string_constant(expr, result);
Copy link
Collaborator

Choose a reason for hiding this comment

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

const

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: 9a6e16f).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/86143603

@NlightNFotis
Copy link
Contributor Author

@tautschnig I decided on an alternative approach to the bugged test (the one we had a divergent behaviour from gcc and clang).

Before the refactoring work, that turned a line in goto_convertt::convert_switch in line 1252 from an assert to a DATA_INVARIANT. It seems that both of these behaviours are wrong to begin with, and I consider this a bug. For this reason I added a KNOWNBUG test, that I will mark as CORE in another PR, that I will submit on top of this PR fixing this, and in which I will only have the removal of the assertion and the activation of the test. So consider this one at a reviewable state.

NlightNFotis and others added 3 commits September 27, 2018 16:50
Refactor a function in goto_convertt so that it becomes
more comprehensible.
Change some data_invariants to invariants_with_diagnostics
where they are more appropriate, and remove some duplicate
invariants, where they are guaranteed by construction of the
types themselves.
@NlightNFotis
Copy link
Contributor Author

I pushed #3055 that fixes this the issue suggested above. That PR also for now contains the changes introduced here, but once this one is merged, I will rebase that one appropriately to only mirror the change it introduces.

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: 5e7e55a).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/86177330
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.

Passed Diffblue compatibility checks (cbmc commit: 5523818).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/86177840

@tautschnig tautschnig merged commit 0914275 into diffblue:develop Sep 27, 2018
@NlightNFotis NlightNFotis deleted the 2814_takeover branch February 19, 2021 10:48
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