why3 issueshttps://gitlab.inria.fr/why3/why3/-/issues2021-03-15T11:17:04Zhttps://gitlab.inria.fr/why3/why3/-/issues/229Adding location to SP generated variables2021-03-15T11:17:04ZDAILLER SylvainAdding location to SP generated variablesHello,
I don't know if I already opened an issue for this but there should be locations for ident generated by the sp_expr function in vc.ml. In this part of the code, I would like the None locations to be replaced by the appropriate locations:
```
let fresh_wr2 v _ = clone_pv None v in
let fresh_rd2 v _ = if v.pv_ity.ity_pure then None
else Some (clone_pv None v) in
```
This is apparently possible to do by adding a location to constructor Kseq and then propagating it.
A test for checking that it works is simply to create several assignments in a function and look at the generated task. If the constants of the generated task don't have locations, it does not work.Hello,
I don't know if I already opened an issue for this but there should be locations for ident generated by the sp_expr function in vc.ml. In this part of the code, I would like the None locations to be replaced by the appropriate locations:
```
let fresh_wr2 v _ = clone_pv None v in
let fresh_rd2 v _ = if v.pv_ity.ity_pure then None
else Some (clone_pv None v) in
```
This is apparently possible to do by adding a location to constructor Kseq and then propagating it.
A test for checking that it works is simply to create several assignments in a function and look at the generated task. If the constants of the generated task don't have locations, it does not work.Andrei PaskevichAndrei Paskevichhttps://gitlab.inria.fr/why3/why3/-/issues/287Add injectivity for type invariant2021-02-05T14:04:11ZFrançois BobotAdd injectivity for type invariant```
type t = {
v: int;
} invariant { 0 <= v }
```
It is currently not possible to prove that:
```
forall x1 x2:t. x1.v = x2.v -> x1 = x2
```
Which is compiled to:
```
forall x1 x2:t. (view x1).v = (view x2).v -> x1 = x2
```
We need to add the property that `view` is injective, for example using `mk` its inverse:
```
forall x:t [view x]. mk (view x) = x
```
# Decision #
> So, we agreed that adding `t'mk` for constructing a non-private type `t` from its fields is a good idea.```
type t = {
v: int;
} invariant { 0 <= v }
```
It is currently not possible to prove that:
```
forall x1 x2:t. x1.v = x2.v -> x1 = x2
```
Which is compiled to:
```
forall x1 x2:t. (view x1).v = (view x2).v -> x1 = x2
```
We need to add the property that `view` is injective, for example using `mk` its inverse:
```
forall x:t [view x]. mk (view x) = x
```
# Decision #
> So, we agreed that adding `t'mk` for constructing a non-private type `t` from its fields is a good idea.1.5.0François BobotFrançois Bobothttps://gitlab.inria.fr/why3/why3/-/issues/344Lost location for function argument2019-06-26T08:44:49ZDAILLER SylvainLost location for function argumentIn the following example:
```
type t = { mutable f : int }
let set (x : t) (v : int) ensures { x.f = v} =
x.f <- v
let g (a : t) =
set a 42;
assert { a.f = 43}
```
The following task is generated:
```
[...]
axiom H :
#"bench/ce/bug/../bug.mlw" 8 2 10#
(#"bench/ce/bug/../bug.mlw" 4 36 37# a)
= (#"bench/ce/bug/../bug.mlw" 8 8 10# 42)
[...]
```
The second location apparently refers to the declaration of field `f`. It should not appear here. Only the first location (on line 8), should be kept.In the following example:
```
type t = { mutable f : int }
let set (x : t) (v : int) ensures { x.f = v} =
x.f <- v
let g (a : t) =
set a 42;
assert { a.f = 43}
```
The following task is generated:
```
[...]
axiom H :
#"bench/ce/bug/../bug.mlw" 8 2 10#
(#"bench/ce/bug/../bug.mlw" 4 36 37# a)
= (#"bench/ce/bug/../bug.mlw" 8 8 10# 42)
[...]
```
The second location apparently refers to the declaration of field `f`. It should not appear here. Only the first location (on line 8), should be kept.Andrei PaskevichAndrei Paskevichhttps://gitlab.inria.fr/why3/why3/-/issues/393type invariant preservation question2019-11-27T12:19:54ZDAILLER Sylvaintype invariant preservation questionI have a quite simple question about the behavior of type invariant. In the simple program below, I am asked by the tool to prove a type invariant inside function `g` for variable `e` (after split). I would have expected this invariant to be ensured in the proof for `f`. Is there a way to tell the tool "at this point of program type invariants should hold" ?
```
module Example
type r = { mutable p: int }
invariant { p = 42 }
let f (e: r)
writes {e}
ensures { true }
=
e.p <- 42
let g ()
diverges
=
let e: r = { p = 42 } in
while true do
f (e);
done
end
```I have a quite simple question about the behavior of type invariant. In the simple program below, I am asked by the tool to prove a type invariant inside function `g` for variable `e` (after split). I would have expected this invariant to be ensured in the proof for `f`. Is there a way to tell the tool "at this point of program type invariants should hold" ?
```
module Example
type r = { mutable p: int }
invariant { p = 42 }
let f (e: r)
writes {e}
ensures { true }
=
e.p <- 42
let g ()
diverges
=
let e: r = { p = 42 } in
while true do
f (e);
done
end
```https://gitlab.inria.fr/why3/why3/-/issues/490Function symbol not found in a block of mutually recursive definitions2020-06-23T16:50:33ZMário PereiraFunction symbol not found in a block of mutually recursive definitionsConsider the following example:
```
let rec function f (x: int)
ensures { result = g x }
=
g x
with function g (x: int) =
f x
```
Why3 complains with an unbound function error for the postcondition of `f`. Is this the expected behavior? Since `g` is defined using `with function`, I supposed it would be bound also for the contract of `f`.Consider the following example:
```
let rec function f (x: int)
ensures { result = g x }
=
g x
with function g (x: int) =
f x
```
Why3 complains with an unbound function error for the postcondition of `f`. Is this the expected behavior? Since `g` is defined using `with function`, I supposed it would be bound also for the contract of `f`.