@@ -20,11 +20,11 @@ let[@zero_alloc] f_call_var x = M_alloc_var.f_alloc2 x
20
20
21
21
22
22
(* Arity: The typing tests show that if we just give this function the signature
23
- [val[@zero_alloc] f_arity_two : int -> int -> int] we'll get a type error.
23
+ [val[@zero_alloc] f_arity_one : int -> int -> int] we'll get a type error.
24
24
Here we show that if we give it a signature that passes the typechecker (the
25
- mli has [val[@zero_alloc (arity 1)] f_arity_two : int -> int -> int]), it
25
+ mli has [val[@zero_alloc (arity 1)] f_arity_one : int -> int -> int]), it
26
26
correctly gets checked and gives a zero_alloc backend error. *)
27
- let f_arity_two x = fun y -> x + y
27
+ let f_arity_one x = fun y -> x + y
28
28
29
29
30
30
(* Shadowing: the mli marks [f_shadow] zero_alloc. That check should only apply
@@ -34,6 +34,12 @@ let f_shadow x = (x, x+1)
34
34
35
35
let f_shadow _x = (42 , 43 ) (* doesn't allocate because this is static. *)
36
36
37
+ (* Shadowing: the other way. This time the function exposed in the signature
38
+ does allocate, and we should get an error for it. *)
39
+ let f_shadow_alloc _x = (42 , 43 )
40
+
41
+ let f_shadow_alloc x = (x, x)
42
+
37
43
(* And now the boring part - just a test that we check each function below with
38
44
the exact parameters implied by the signature (opt, strict). *)
39
45
0 commit comments