dynamic-extent closure should imply dynamic-extent value cells

[James Y Knight]

Currently, in emit-make-value-cell, it decides whether to d-x allocate the value cells based on whether there's a TRULY-DYNAMIC-EXTENT declaration for the node. This is bogus: value cells' extent need not and should not have any thing to do with the extent of the value contained within.

Even if bug #308934 was fixed, relaxing the check to work with a "non-truly" dynamic-extent declaration still be wrong: the definition of dynamic extent talks about the extent of the *values*, not the binding itself. E.g. consider the following code. It should work, and SBCL would be broken to make it crash by d-x allocating the value-cell for VAL.

(defvar *items* '(a b c d e f g h i j))

(defun make-counter ()
  (let ((val *items*))
    (declare (dynamic-extent val))
    (lambda ()
      (prog1 (car val)
        (setf val (cdr val))))))

What SBCL should be doing is looking at the dynamic-extent declarations on the closures *accessing* the value cells. If all accesses to the value cells are from dynamic-extent-declared closures, or are from the original function, allocate the value cell dynamic extent, otherwise don't. D-x declarations for the binding itself should be examined.

Here's an example of code that should not cons, but currently does in SBCL:

(defun should-not-cons ()
  (let ((test 0))
    (labels ((foo ()
               (incf test)))
      (declare (dynamic-extent #'foo))
      (foo)
      (foo)
      test)))

(Actually, ideally, dynamic-extent value cells wouldn't be created at all: the dynamic-extent function would simply reference the variables directly in the containing function's stack frame. The d-x function would need to be passed the address of the start of the used frame, of course.)

[[ Tested with SBCL 1.0.38.12 on Linux x86-64 ]]

[Alastair Bridgewater (alastair-bridgewater)]

In 1.0.44.16 (the "ideal" case).