Skip to content

Add support for incremental SMT traces containing C_bool #6628

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 3 commits into from
Feb 2, 2022

Conversation

thomasspriggs
Copy link
Contributor

An "unsupported type" invariant violation would previously have been
encountered when attempting to generate traces featuring c_bool_typet.
This is due to c_bool_typet not being castable to
integer_bitvector_typet.

  • Each commit message has a non-empty body, explaining why the change was made.
  • Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
  • The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
  • 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).
  • 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.

@codecov
Copy link

codecov bot commented Feb 2, 2022

Codecov Report

Merging #6628 (a638644) into develop (3f03433) will increase coverage by 0.00%.
The diff coverage is 100.00%.

Impacted file tree graph

@@           Coverage Diff            @@
##           develop    #6628   +/-   ##
========================================
  Coverage    76.64%   76.65%           
========================================
  Files         1579     1580    +1     
  Lines       181487   181560   +73     
========================================
+ Hits        139109   139168   +59     
- Misses       42378    42392   +14     
Impacted Files Coverage Δ
...smt2_incremental/construct_value_expr_from_smt.cpp 100.00% <ø> (ø)
...smt2_incremental/construct_value_expr_from_smt.cpp 100.00% <100.00%> (ø)
...trument/contracts/havoc_assigns_clause_targets.cpp 95.55% <0.00%> (-4.45%) ⬇️
src/goto-instrument/contracts/utils.cpp 85.59% <0.00%> (-4.10%) ⬇️
src/goto-instrument/contracts/contracts.cpp 90.75% <0.00%> (-0.63%) ⬇️
src/ansi-c/c_typecheck_code.cpp 79.92% <0.00%> (-0.19%) ⬇️
.../goto-instrument/goto_instrument_parse_options.cpp 69.24% <0.00%> (-0.08%) ⬇️
src/ansi-c/c_expr.h 100.00% <0.00%> (ø)
src/goto-instrument/contracts/utils.h 100.00% <0.00%> (ø)
src/goto-programs/restrict_function_pointers.h 100.00% <0.00%> (ø)
... and 8 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f2240be...a638644. Read the comment docs.

Copy link
Contributor

@TGWDB TGWDB left a comment

Choose a reason for hiding this comment

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

LGTM

It would have been prettier to have split commits for parts that are different (e.g. refactor, code reorder, tests), but for a PR this small it's fine.

int x, y;
bool equal = x == y;
__CPROVER_assert(equal, "Assert of integer equality.");
__CPROVER_assert(!equal, "Assert of not integer equality.");
Copy link
Contributor

Choose a reason for hiding this comment

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

⛏️ What does not integer equality mean? Do you mean inequality in this context?

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 mean the not operator is being applied to the result of testing for integer equality. This is equivalent to testing for inequality with the != operator, so the distinction is not really important here. The main purpose of this assertion is to ensure that the output traces include instances where equal is assigned a true value and equal is assigned a false value.

An "unsupported type" invariant violation would previously have been
encountered when attempting to generate traces featuring `c_bool_typet`.
This is due to `c_bool_typet` not being castable to
`integer_bitvector_typet`.
The following commit is adding an include which will cause the updated
version of clang-format to re-order the includes. Doing the reorder in
advance will make it clear which include is added.
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