No test program is left from the move-only rule for Vec that nothing checks any more
This commit is contained in:
parent
e511174d3c
commit
2b42cecded
@ -1,8 +0,0 @@
|
||||
;;;; `free` consumes its argument exactly as any other move does, so the second
|
||||
;;;; one is a compile error rather than a runtime crash. Nothing analyses this
|
||||
;;;; specially: it is the same dead-binding rule as passing one to a function.
|
||||
(defn main [] i32
|
||||
(let [v (vec-new i32)]
|
||||
(free v)
|
||||
(free v)
|
||||
0))
|
||||
@ -1,8 +0,0 @@
|
||||
;;;; A loop body that moves a binding declared outside the loop: the second
|
||||
;;;; iteration would use what the first gave away. The dead set alone cannot
|
||||
;;;; see this — merged once at the end of the body it counts one move, not two
|
||||
;;;; — so it is a rule, and it is refused with the reason.
|
||||
(defn main [] i32
|
||||
(let [v (vec-new i32)]
|
||||
(dotimes [i 3] (free v))
|
||||
0))
|
||||
@ -1,15 +0,0 @@
|
||||
;;;; A Vec is move-only: passing one to a function transfers ownership, and the
|
||||
;;;; source binding is dead afterwards. That rule is what makes a double free
|
||||
;;;; unrepresentable, which is why `free` needs no analysis of its own.
|
||||
(defn take [v (Vec i32)] i32
|
||||
(let [n (length v)]
|
||||
(free v)
|
||||
n))
|
||||
|
||||
(defn main [] i32
|
||||
(let [v (vec-new i32)]
|
||||
(push v 1)
|
||||
(println (take v))
|
||||
;; v went with the call. Being refused here is the whole test.
|
||||
(println (length v))
|
||||
0))
|
||||
@ -179,8 +179,8 @@ let check label path args ~checks =
|
||||
- dev-* and reload-*, which need a host process or a dlopen harness.
|
||||
- the compile-time refusals: nth-gone, pkg-hidden-main, pkg-two-aliases,
|
||||
pkg-two-mains, pkg-cycle, pkg-alias-clash, user-allocator, and the whole
|
||||
vec-moved / vec-double-free / vec-in-struct / vec-global / vec-to-c /
|
||||
vec-untyped family. These never produce a binary at all: the
|
||||
vec-in-struct / vec-global / vec-to-c / vec-untyped family. These never
|
||||
produce a binary at all: the
|
||||
checker refuses them, which is the point of them. There is nothing for
|
||||
memcheck to run.
|
||||
- shadow-pkg.flan, which is a package fragment with no main and does not
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user