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

Inconsistent positions for postcondition #1480

Open
mario-bucev opened this issue Nov 9, 2023 · 1 comment
Open

Inconsistent positions for postcondition #1480

mario-bucev opened this issue Nov 9, 2023 · 1 comment

Comments

@mario-bucev
Copy link
Collaborator

The following snippet:

import stainless.lang._
import StaticChecks._

def test(x: BigInt): (BigInt, BigInt) = {
  var y = x + x // var!
  var z = y + y
  (y, z)
}.ensuring((y, z) => z >= 0)

gives the following position for the VC:

[Warning ] TaystPostcondMin.scala:8:13:  => INVALID
           }.ensuring((y, z) => z >= 0)
                       ^

which seems to say that y is responsible for the invalidity but is just an artifact of the postcondition position.
If however we use vals, we have:

[Warning ] TaystPostcondMin.scala:7:3:  => INVALID
             (y, z)
             ^^^^^^

which is meaningful.
On the other hand, we do not use StaticChecks.ensuring (whether we use var or val), we get:

[Warning ] TaystPostcondMin.scala:8:22:  => INVALID
           }.ensuring((y, z) => z >= 0)
                                ^^^^^^

so we get 3 different positions for small tweaks. If we can at least rule out 1, that would be great. If we can make it consistent, that would be even better (we should however choose between option 2 and 3, I'd say 2 is more consistent because this is the positions we get in presence of branches).

@vkuncak
Copy link
Collaborator

vkuncak commented Nov 11, 2023

This does not seem like a huge problem to me. In the end, the user may want to see the verification condition. But I was not aware that we write "INVALID" only on the error position line. This may be making the issue more sensitive. In reality, the definitions and paths also affect the validity. I get, for example the report (with --no-colors, but the issue is same anyway):

warning: val y: BigInt = x + x
y + y >= BigInt("0")
Test.scala:8:13: warning:  => INVALID
           }.ensuring((y, z) => z >= 0)

Should this not be printed as:

warning:
Test.scala:8:13: warning:  => INVALID
val y: BigInt = x + x
y + y >= BigInt("0")
           }.ensuring((y, z) => z >= 0)
                         ^

Namely, only the ^ sign affected by the position, not the "warning INVALID"?

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

No branches or pull requests

2 participants