GitLab

Program functions can be declared as partial with "let/val partial".
Similarly to "diverges", partial code cannot be ghost, however it does not need to be
explicitly specified as partial.

Fixes #184.

Sept merge new ide

Closes #161 and #160

See merge request !24

This intends to add improvements that were done in new_ide but not merged
in master yet.
In particular, this merges
- the commit for interruption of provers in why3server.
- several counterexamples improvements:
  * choice of pretty printing for float counterexamples
  * countereamples parsing of lowercase "lambda"
- itp_server/controller_itp improvements:
  * error handling in itp_server (any_from_node_ID is now option)
  * reformating of controller_itp queues as record instead of tuples
  * choice to always give a new goal with the automatic function that gets
next goal

Conflicts:
	bench/ce/algebraic_type_CVC4,1.5.oracle
	bench/ce/algebraic_type_Z3,4.6.0.oracle
	bench/ce/array_records_CVC4,1.5.oracle
	bench/ce/array_records_Z3,4.6.0.oracle
	bench/ce/arrays_CVC4,1.5.oracle
	bench/ce/arrays_Z3,4.6.0.oracle
	bench/ce/floats_CVC4,1.5.oracle
	bench/ce/floats_Z3,4.6.0.oracle
	bench/ce/if_decision_branch.mlw
	bench/ce/if_decision_branch_CVC4,1.5.oracle
	bench/ce/if_decision_branch_Z3,4.6.0.oracle
	bench/ce/int.mlw
	bench/ce/int32_CVC4,1.5.oracle
	bench/ce/int32_Z3,4.6.0.oracle
	bench/ce/int_CVC4,1.5.oracle
	bench/ce/int_Z3,4.6.0.oracle
	bench/ce/int_overflow_CVC4,1.5.oracle
	bench/ce/int_overflow_Z3,4.6.0.oracle
	bench/ce/jlamp0_CVC4,1.5.oracle
	bench/ce/jlamp0_Z3,4.6.0.oracle
	bench/ce/jlamp_array_CVC4,1.5.oracle
	bench/ce/jlamp_array_Z3,4.6.0.oracle
	bench/ce/jlamp_projections_CVC4,1.5.oracle
	bench/ce/jlamp_projections_Z3,4.6.0.oracle
	bench/ce/map_CVC4,1.5.oracle
	bench/ce/map_Z3,4.6.0.oracle
	bench/ce/real_CVC4,1.5.oracle
	bench/ce/real_Z3,4.6.0.oracle
	bench/ce/record_map_CVC4,1.5.oracle
	bench/ce/record_map_Z3,4.6.0.oracle
	bench/ce/records_CVC4,1.5.oracle
	bench/ce/records_Z3,4.6.0.oracle
	bench/ce/ref_CVC4,1.5.oracle
	bench/ce/ref_Z3,4.6.0.oracle
	bench/ce/simple_array_CVC4,1.5.oracle
	bench/ce/simple_array_Z3,4.6.0.oracle
	src/core/ident.ml
	src/core/ident.mli
	src/parser/parser.mly
	src/printer/alt_ergo.ml
	src/printer/smtv2.ml
	src/session/itp_server.ml
	src/transform/eval_match.ml
	src/transform/intro_projections_counterexmp.ml
	src/transform/intro_vc_vars_counterexmp.ml
	src/whyml/mlw_wp.ml
	tests/demo-itp.mlw

not updated:
- stdlib/array - the proof is broken
- ring_decision/ - not replayed, proof broken
- in_progress/, util/, prover/bench/ - not replayed

[transform apply] let is now a premise for applied condition of apply

See merge request !23

For framac

See merge request !21

This reverts commit ce0b3584.

Counterexample:

predicate rev (x y:int) = x <= 1 /\ x > y
let rec function
     f1 () : () variant { 0, 1, 0 }          = f2 ()
with f2 () : () variant { 0, 0, 1 }          = f3 ()
with f3 () : () variant { 0, 0 with rev, 0 } = f4 ()
with f4 () : () variant { 0, 1 with rev, 1 } = f1 ()

When extracting a [try e with..] expressions, we must propagate the user mask to the extraction of [e]

1. better handle the equality case, which is the reason for using a
   lexicographic order in the first place;
2. implement a proper lexicographic order, i.e., make (a,b) smaller
   than (a,b,c).

As a consequence of these two changes, in the following example, the VC
for f goes from (0 <= x /\ x < x) to true:

let rec f (x y : int) : int variant { x, () } = g x y
with g (x y : int) : int variant { x } = f (x-1) y

This closes issue #181.

Short story: it was a source of bugs, there was only one handcrafted
message over 650, and, to quote François Pottier, "you seem to have
misunderstood what the various commands do".

Long story: the proper steps to update the error messages after modifying
the parser are

1. update the old states with --update-errors
2. generate the new states with --list-errors
3. compare the old and new states with --compare-errors
4. manually reconcile the differences between the old and new states
5. write error messages for the new states
6. add %on_error_reduce and go back to step 1, if step 5 is too hard
7. check that the error messages for the old states are still meaningful
8. check that the set of states is both correct (--compile-errors) and
   complete (--compare-errors)

We were doing only step 1 and half of step 8. Doing the other half of
step 8 would have prevented issue #172 from occurring. But that would have
meant doing step 4 after each parser modification, which was never done.
Note that step 2 is so expensive that it is impossible to perform step 8
during continuous integration.

Given the work needed to update the error messages after a syntax change,
I don't think we can reliably use them until WhyML no longer evolves.