- 25 Apr, 2013 4 commits
-
-
Jean-Christophe Filliâtre authored
-
Jean-Christophe Filliâtre authored
-
François Bobot authored
-
Andrei Paskevich authored
By popular demand, read effects are back. They serve to mark dependence of a program function on external variables which are otherwise not mentioned in the function's specification. Such annotation is necessary, for example, to add the needed type invariants. The "reads" clauses are comma-separated variables (contrary to write effects, where one must point out the modified field). If a user specifies a "reads" clause for a defined function, we check that every listed variable occurs in the code and that every free variable in the code occurs in the specification (which includes the "reads" clause). Notice that this concers function arguments, too: val r : ref int let f (x : ref int) reads {r} = x := !r would require x to be added to reads.
-
- 24 Apr, 2013 3 commits
-
-
Andrei Paskevich authored
-
Andrei Paskevich authored
-
Jean-Christophe Filliâtre authored
-
- 23 Apr, 2013 1 commit
-
-
Andrei Paskevich authored
-
- 22 Apr, 2013 3 commits
-
-
Andrei Paskevich authored
-
Andrei Paskevich authored
One exception to this rule is the the result type in a non-recursive function may contain regions coming the function's arguments (though not from the context). It is sometimes useful to write a function around a constructor or a projection: see function [create] in verifythis_fm2012_LRS.mlw. For recursive functions we impose the full non-alias discipline.
-
Andrei Paskevich authored
-
- 21 Apr, 2013 1 commit
-
-
Guillaume Melquiond authored
-
- 18 Apr, 2013 1 commit
-
-
Andrei Paskevich authored
-
- 17 Apr, 2013 2 commits
-
-
Andrei Paskevich authored
-
MARCHE Claude authored
-
- 16 Apr, 2013 3 commits
-
-
Andrei Paskevich authored
-
Andrei Paskevich authored
-
Jean-Christophe Filliâtre authored
-
- 15 Apr, 2013 3 commits
-
-
MARCHE Claude authored
-
Martin Clochard authored
-
MARCHE Claude authored
-
- 13 Apr, 2013 2 commits
-
-
MARCHE Claude authored
-
MARCHE Claude authored
-
- 11 Apr, 2013 3 commits
-
-
Jean-Christophe Filliâtre authored
-
Jean-Christophe Filliâtre authored
-
Jean-Christophe Filliâtre authored
-
- 10 Apr, 2013 2 commits
-
-
Jean-Christophe Filliâtre authored
-
Jean-Christophe Filliâtre authored
-
- 09 Apr, 2013 6 commits
-
-
Jean-Christophe Filliâtre authored
-
François Bobot authored
-
Jean-Christophe Filliâtre authored
-
Jean-Christophe Filliâtre authored
-
Jean-Christophe Filliâtre authored
-
François Bobot authored
-
- 08 Apr, 2013 3 commits
-
-
Andrei Paskevich authored
-
Andrei Paskevich authored
-
Jean-Christophe Filliâtre authored
-
- 07 Apr, 2013 3 commits
-
-
Andrei Paskevich authored
-
Andrei Paskevich authored
Now that ghost writes are checked via e_syms.syms_pv, there is no use for read effects anymore.
-
Andrei Paskevich authored
This fixes one bug and several deficiencies in the previous implementation, which was based on read effects. One caveat about the current version is that we treat all type variables in a polymorphic type as visible (= non-ghost) even if they only occur in the ghost fields. For example, the following code is rejected: type strange 'a = { ghost contents : 'a } let test () = let x = { contents = ref 0 } in x.contents := 42 Even though the field [contents] is ghost and cannot be reached from the real-world code, the type of x is [strange (ref int)] and the region of the reference is considered to be visible. Thus the last assignment is seen as an illicit ghost write. On the other hand, type strange 'a = { ghost contents : ref 'a } and type strange 'a = { ghost mutable contents : 'a } permit ghost writes into [contents] without problem. Ghost writes into ghost variables are also okay.
-