Skip to content

_Static_assert failures should be reported in the front-end #5677

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
Dec 21, 2020

Conversation

tautschnig
Copy link
Collaborator

We left it to a failing invariant in goto-program conversion to detect a
failing (local) _Static_assert. Global _Static_assert statements were
not verified at all.

  • Each commit message has a non-empty body, explaining why the change was made.
  • n/a Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
  • n/a 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).
  • n/a My commit message includes data points confirming performance improvements (if claimed).
  • My PR is restricted to a single feature or bugfix.
  • n/a White-space or formatting changes outside the feature-related changed lines are in commits of their own.

@codecov
Copy link

codecov bot commented Dec 18, 2020

Codecov Report

Merging #5677 (d80f750) into develop (4c2b413) will decrease coverage by 0.00%.
The diff coverage is 77.41%.

Impacted file tree graph

@@             Coverage Diff             @@
##           develop    #5677      +/-   ##
===========================================
- Coverage    69.45%   69.45%   -0.01%     
===========================================
  Files         1243     1243              
  Lines       100620   100639      +19     
===========================================
+ Hits         69887    69899      +12     
- Misses       30733    30740       +7     
Flag Coverage Δ
cproversmt2 43.13% <12.90%> (-0.01%) ⬇️
regression 66.34% <77.41%> (-0.01%) ⬇️
unit 32.27% <0.00%> (-0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
src/ansi-c/c_typecheck_type.cpp 76.87% <33.33%> (-0.21%) ⬇️
src/ansi-c/c_typecheck_expr.cpp 75.31% <42.85%> (-0.17%) ⬇️
src/ansi-c/scanner.l 63.99% <80.00%> (+0.04%) ⬆️
src/ansi-c/c_typecheck_base.cpp 81.25% <100.00%> (-0.07%) ⬇️
src/ansi-c/c_typecheck_code.cpp 82.40% <100.00%> (+0.42%) ⬆️
src/cpp/cpp_typecheck_static_assert.cpp 60.00% <100.00%> (+13.84%) ⬆️
src/util/simplify_expr_floatbv.cpp 95.04% <100.00%> (+0.04%) ⬆️
src/util/simplify_expr.cpp 87.82% <0.00%> (-0.31%) ⬇️

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 4c2b413...d80f750. Read the comment docs.

Copy link
Collaborator

@martin-cs martin-cs left a comment

Choose a reason for hiding this comment

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

OK but I do wonder whether we should treat these like asserts. I guess the point is that they are supposed to be build time and if they fail then the code is explicitly marked as being wrong.

typecheck_expr(code.op0());
typecheck_expr(code.op1());

code.op0() = typecast_exprt::conditional_cast(code.op0(), bool_typet{});
Copy link
Member

Choose a reason for hiding this comment

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

That might not work, consider implicit_typecast_bool?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Done!

@tautschnig
Copy link
Collaborator Author

#5679 needs to be merged first to make CI happy again.

@@ -20,9 +20,6 @@ Author: Daniel Kroening, [email protected]
simplify_exprt::resultt<>
simplify_exprt::simplify_isinf(const unary_exprt &expr)
{
if(expr.op().type().id() != ID_floatbv)
Copy link
Member

Choose a reason for hiding this comment

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

I would leave that as a PRECONDITION.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Could do, but would be redundant with to_floatbv_type(expr.type()) that ieee_floatt::from_expr does. I'm happy to add it for clarity, but if so I'd suggest to add it to simplify_isnan and simplify_isnormal as well?

Copy link
Member

Choose a reason for hiding this comment

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

Yes, please add, the idea being "fail early" and "clarity".

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Done!

This isn't necessarily spelled out in the signature of the function, but
GCC's documentation states this requirement.
Fail early if simplification encounters non-floatbv operands to these
functions. This would have been caught by ieee_floatt::from_expr, but
failing early makes diagnosing easier.
We left it to a failing invariant in goto-program conversion to detect a
failing (local) _Static_assert. Global _Static_assert statements were
not verified at all.
@tautschnig tautschnig merged commit 4c51ce9 into diffblue:develop Dec 21, 2020
@tautschnig tautschnig deleted the static-assert branch December 21, 2020 16:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants