Skip to content
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

Extend /testContracts to be able to test contracts on any function/method #3151

Open
atomb opened this issue Dec 2, 2022 · 1 comment
Open
Assignees
Labels
kind: enhancement Enhancements, feature requests, etc. These are NOT bugs, but ways we can improve Dafny

Comments

@atomb
Copy link
Member

atomb commented Dec 2, 2022

Summary

It could be useful to allow any (compilable) contract clause to be checked at runtime. This would make it possible to test code that's difficult to prove. In the extreme case, you could compile with this turned on and /noVerify and have a system more like Eiffel.

Background and Motivation

PR #2712 introduced the /testContracts flag, which adds runtime checks for certain functions and methods. In particular it supports checking contracts dynamically on either:

  • All externs
  • Any extern called directly from a test

The original goal was to extend this to support a larger range of code, and not leave it restricted to externs.

Proposed Feature

Add a parameter to /testContracts, perhaps /testContracts:All to insert runtime checks for all compilable contract clauses (with warnings for any that aren't compilable, as are already present for externs).

Alternatives

No response

@atomb atomb added the kind: enhancement Enhancements, feature requests, etc. These are NOT bugs, but ways we can improve Dafny label Dec 2, 2022
@atomb atomb self-assigned this Dec 2, 2022
@atomb
Copy link
Member Author

atomb commented Dec 19, 2022

After experimenting with a command-line option that disables all filtering, therefore applying runtime contract testing to all functions and methods, there seem to be a handful of failures that show up:

  • The current code fails on constructors, as it's not possible to create a new constructor that wraps an old one. We'll either need to explicitly skip constructors (and warn if they have contracts?) or come up with a cleverer encoding to deal with them.
  • There's an assertion in the QuantifierExpr class that occasionally fails.
  • The UselessOldLinter sometimes fails.
  • Some generated wrappers fail to type check because of what I think is an instance of Dafny fails to check type characteristics in specification clauses #3150. If I'm right about that, it's a bug in the Dafny input code, not in the /testContracts implementation. Can be replicated with this file.
  • Duplicate wrappers with the same name sometimes show up. Can be replicated with this file.
  • Null dereference in Dafny.Resolver.FrameArrowToObjectSet. Can be replicated with this file.
  • Null dereference in Triggers.TriggersCollector.TranslateToFunctionCall. Can be replicated with this file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: enhancement Enhancements, feature requests, etc. These are NOT bugs, but ways we can improve Dafny
Projects
None yet
Development

No branches or pull requests

1 participant