Slot access failure in interpreted mode

[Jonathan Braud]

When using the interpreter, accessing a slot fails in some situations. After evaluating this:

    (setq *evaluator-mode* :interpret)

    (defclass foo () ((x :initform 123)))

    (defun foo-x-0 (foo)
      (slot-value foo 'x))

    (defmethod foo-x-1 ((foo foo))
      (slot-value foo 'x))

    (defmethod foo-x-2 ((foo foo))
      (let ((%foo foo))
        (slot-value %foo 'x)))

    (defmethod foo-x-3 ((foo t))
      (slot-value foo 'x))

I get the following results:

    (foo-x-0 (make-instance 'foo)) => ERROR
    (foo-x-1 (make-instance 'foo)) => 123
    (foo-x-2 (make-instance 'foo)) => ERROR
    (foo-x-3 (make-instance 'foo)) => ERROR

The error is:

  The function
  (SB-PCL::SLOT-ACCESSOR :GLOBAL COMMON-LISP-USER::X SB-PCL::READER) is
  undefined.

There is no such problem when *EVALUATOR-MODE* is :COMPILE.

Looking at the FUNCTION-LAMBDA-EXPRESSION of the four functions, the slot access goes through a call to:

  For foo-x-0: SLOT-VALUE
  For foo-x-1: SB-PCL::OPTIMIZED-SLOT-VALUE
  For foo-x-2: SB-PCL::ACCESSOR-SLOT-VALUE
  For foo-x-3: SB-PCL::ACCESSOR-SLOT-VALUE

(Presumably because FOO-X-1 knows the type of the first argument to SLOT-VALUE but the other functions don't.)

It looks like the compiler defines the function (SB-PCL::SLOT-ACCESSOR :GLOBAL COMMON-LISP-USER::X SB-PCL::READER) but the interpreter doesn't, because simply compiling FOO-X-0 makes everything right:

    (compile 'foo-x-0)
    (foo-x-3 (make-instance 'foo)) => 123
    (foo-x-2 (make-instance 'foo)) => 123
    (foo-x-1 (make-instance 'foo)) => 123
    (foo-x-0 (make-instance 'foo)) => 123

The problem persists in version 2.3.2.8-63bafe1ba.

uname -a: Linux io 6.1.12-arch1-1 #1 SMP PREEMPT_DYNAMIC Tue, 14 Feb 2023 22:08:08 +0000 x86_64 GNU/Linux

*FEATURES*:
(:ARENA-ALLOCATOR :X86-64 :GENCGC :64-BIT :ANSI-CL :COMMON-LISP :ELF
 :IEEE-FLOATING-POINT :LINUX :LITTLE-ENDIAN :PACKAGE-LOCAL-NICKNAMES :SB-LDB
 :SB-PACKAGE-LOCKS :SB-THREAD :SB-UNICODE :SBCL :UNIX)

[Stas Boukarev (stassats)]

Not a problem with sb-fasteval.

[Stas Boukarev (stassats)]

Maybe it's time to leave just sb-fasteval?

[Christophe Rhodes (csr21-cantab)]

Thanks for the report. Does the attached patch fix things for you more generally?

[Douglas Katzman (dougk)]

I agree with Stas. Anything sb-eval can do, sb-fasteval can do better.

[Jonathan Braud (jathd)]

Thanks for the patch, it fixes the problem.

(BTW: I wasn't aware of the sb-fasteval option because I'm simply using my distro's default sbcl package, which builds with --fancy. Same goes for Ubuntu and Debian. If there's no downside to using sb-fasteval, maybe it should be included in --fancy?)