Skip to content

Invariant with diagnostics #2906

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

Conversation

hannes-steffenhagen-diffblue
Copy link
Contributor

Framework for putting arbitrary diagnostics on invariants.

Ideally, we should never need this because of course saying something is INVARIANT means we're pretty sure it's always true, but we get the situation that we do unexpected violate an invariant sometimes and in that case we want to give at least a hint of where we went wrong to make it easier for people to create small reproducers.

This is similar to a previous PR which added some ways to add things like source locations onto invariants, this is meant to be more general in case we need to add new kinds of diagnostics or new ways to output them (e.g. as XML or JSON instead of plain text). It doesn't do that right now though.

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: 702ab09).
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).

@johnnonweiler
Copy link
Contributor

@peterschrammel and @danpoe, please could you take a quick look at this and see if it does what you want?

Copy link
Contributor

@danpoe danpoe left a comment

Choose a reason for hiding this comment

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

A few minor comments, otherwise looks good to me.

#define CBMC_NORETURN [[noreturn]]
#else
#define CBMC_NORETURN
#endif
// The macros MACRO<n> (e.g., INVARIANT2) are for internal use in this file
// only. The corresponding macros that take a variable number of arguments (see
// further below) should be used instead, which in turn call those with a fixed
Copy link
Contributor

Choose a reason for hiding this comment

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

These comments can be removed, and the lines following right after that still contain the macros INVARIANT3, etc. should be adapted to the new macros.

std::ostringstream out;
out << "[ " << diagnostic_as_string(std::forward<T>(first));
write_rest_diagnostics(out, std::forward<Ts>(rest)...);
out << " ]";
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we separate the diagnostics by newlines? Some of them are expected to go over several lines (like expr.pretty()).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point, I'd still want to bracket them somehow - how about

<< EXTRA DIAGNOSTICS >>
D1
D2
...
DN
<< END EXTRA DIAGNOSTICS>>

?

static std::string
diagnostics_as_string(const source_locationt &source_location)
{
return source_location.as_string();
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe we can add a heading too, like "source location:\n" + source_location.as_string().

template <>
struct diagnostics_helpert<dstringt>
{
static std::string diagnostics_as_string(const dstringt &dstring)
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'm considering making this a function that takes a std::ostream& and writes some string representation of its argument there rather than returning string. Thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

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

We can leave this for future work I'd say :)

// only. The corresponding macros that take a variable number of arguments (see
// further below) should be used instead, which in turn call those with a fixed
// number of arguments. For example, if INVARIANT(...) is called with two
// arguments, it calls INVARIANT2().

#if defined(CPROVER_INVARIANT_CPROVER_ASSERT)
Copy link
Contributor

Choose a reason for hiding this comment

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

In the following we should also add the new macro INVARIANT_WITH_DIAGNOSTICS, etc. and remove the macros INVARIANT3, etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done, thanks!

Copy link
Contributor

@danpoe danpoe left a comment

Choose a reason for hiding this comment

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

One additional comment, otherwise this is good to go.

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

This PR failed Diffblue compatibility checks (cbmc commit: 0557549).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/84023225
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: a1595ac).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/84026701

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

@hannes-steffenhagen-diffblue hannes-steffenhagen-diffblue changed the title WIP Invariant with diagnostics Invariant with diagnostics Sep 6, 2018
Copy link
Member

@peterschrammel peterschrammel left a comment

Choose a reason for hiding this comment

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

That's a reasonable solution to separate the replacement work from improving the reporting output.

@hannes-steffenhagen-diffblue hannes-steffenhagen-diffblue merged commit ade3057 into diffblue:develop Sep 7, 2018
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.

5 participants