DEFUN of a DEFMACRO from a locked package kills the original definition

[Roman Marynchak]

SBCL 1.0.38, Linux 32 bit.

Enter this code in REPL:

* (defun defun(x) (error "Hi"))

you will see the next output

; in: LAMBDA NIL
; (SB-INT:NAMED-LAMBDA DEFUN
; (X)
; (BLOCK DEFUN (ERROR "Hi")))
; ==>
; #'(SB-INT:NAMED-LAMBDA DEFUN
; (X)
; (BLOCK DEFUN (ERROR "Hi")))
;
; caught STYLE-WARNING:
; DEFUN was previously defined as a macro.
;
; caught STYLE-WARNING:
; The variable X is defined but never used.
;
; compilation unit finished
; caught 2 STYLE-WARNING conditions
STYLE-WARNING: redefining DEFUN in DEFUN

debugger invoked on a SYMBOL-PACKAGE-LOCKED-ERROR in thread #<THREAD
                                                              "initial thread" RUNNING
                                                              {A9EB801}>:
  Lock on package COMMON-LISP violated when setting fdefinition of DEFUN.
See also:
  The SBCL Manual, Node "Package Locks"
  The ANSI Standard, Section 11.1.2.1.2

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [CONTINUE ] Ignore the package lock.
  1: [IGNORE-ALL ] Ignore all package locks in the context of this operation.
  2: [UNLOCK-PACKAGE] Unlock the package.
  3: [ABORT ] Exit debugger, returning to top level.

(PACKAGE-LOCK-VIOLATION #<PACKAGE "COMMON-LISP">)[:EXTERNAL]
0]

Now enter 3 - that is, we are not going to change DEFUN (right?).

After this, DEFUN becomes modified anyway. This code in REPL will signal the error now:

* (defun f(x) (+ x 1))

debugger invoked on a UNBOUND-VARIABLE in thread #<THREAD
                                                   "initial thread" RUNNING
                                                   {A9EB801}>:
  The variable F is unbound.

Also, this is strange:

* (describe 'defun)

COMMON-LISP:DEFUN
  [symbol]

DEFUN names a compiled function:
  Lambda-list: (&REST ARGS)
  Derived type: (FUNCTION (T) NIL)
  Source file: SYS:SRC;COMPILER;INFO-FUNCTIONS.LISP

Why info-functions.lisp?

Note that the same problems are with COND and other macros. For the functions like EVENP, the package lock works fine, and they are not modified when performing the above steps.

Or I have missed something here?

Regards,
Roman

[Nikodemus Siivola (nikodemus)]

Gah, I'm pretty sure I've already fixes this once. Obviously the test-suite doesn't cover enough...

[Nikodemus Siivola (nikodemus)]

Fixed in SBCL 1.0.42.28.

Re: why info-functions.lisp. Because (SETF MACRO-FUNCTION) also sets the corresponding SYMBOL-FUNCTION to a function that signals an error, so that (FUNCALL #'SOME-MACRO) will complain -- and that function happens to live in info-functions.lisp.