Re: [Sbcl-devel] freeze for sbcl-1.2.5

[Douglas K. <do...@go...>]

I'll take this opportunity to ask about my recently filed
https://bugs.launchpad.net/sbcl/+bug/1383749 which I was going to check in
part 1 of a fix for but didn't get to.  There are (at least) two different
pieces of code which have a "technical" problem, and a general issue in
need of some guidance on best practice. "technical" is in quotes because DX
assertions are used in a way that affects the extra sanity check run by
pre_verify_generation_0 in gencgc.
A minimal example is comprised of these 3 definitions:

(defmacro with-hair (&body body)
  `(sb-int:dx-flet ((thunk1 () ,@body)) (call-with-hair #'thunk1)))

(defmacro with-frob (&body body) `(call-with-frob (lambda () ,@body)))

(defun call-with-hair (f)
  (let ((*hairy-setup* (compute))) (with-frob (funcall f))))

WITH-HAIR says that #'THUNK1 should be on the stack, but the lambda in
WITH-FROB in the implementation of CALL-WITH-HAIR captures its arg on the
heap. The offending macros are WITH-{DEBUG,STANDARD,SANE}-IO-SYNTAX, the
first of which says that a thunk is DX, and the latter two of which don't.
GC mostly doesn't care, as it turns out.

But imagining that GC does care, the solution is to pick whether you want
DX declarations all the way down, or you don't want, because you can't have
it both ways.  The advantage of not having the declaration is that
CALL-WITH-mumble becomes in tail position.

The specific fix I was going to make was that WITH-STANDARD- and WITH-SANE-
could use DX-FLET.  But I'm beginning to wonder if this is a good idea for
macros that users have access to. So then I was going to do the opposite.

The question in here can be expressed concisely as: in as much as the
heap-walking code in GC should not say "ptr sees junk" in the regression
suite, what should we be doing with macros like this ?

Part 2 of the problem is that making those three macros consistent doesn't
actually fix the bug.  There is some more of that going on, and I haven't
found it yet.

Doug