You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Contrary to carbon, it seems the function body/result is not available when establishing the well-formedness of the postcondition:
function require_true(x: Bool): Bool
requires x
{ x }
function f(): Bool
ensures require_true(result)
{ true }
reports:
Silicon found 1 error in 2.27s:
[0] Precondition of function require_true might not hold. Assertion result might not hold. ([email protected])
carbon finished verification successfully in 1.65s.
Of course there is something to be said for requiring contracts to be self-framing, but I am wondering about the difference with carbon :)
The text was updated successfully, but these errors were encountered:
I would consider this intentional behavior, especially now that Viper has opaque functions, which means that for individual function applications, the function body may not be known to the verifier. In that case, the postcondition will still be assumed and IMO should still be well-defined.
Contrary to carbon, it seems the function body/
result
is not available when establishing the well-formedness of the postcondition:reports:
Of course there is something to be said for requiring contracts to be self-framing, but I am wondering about the difference with carbon :)
The text was updated successfully, but these errors were encountered: