minor DEFMETHOD+declarations conformance issue
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
Triaged
|
Low
|
Unassigned |
Bug Description
The CLHS entry for DEFMETHOD states in part:
«Declarations at the head of the method body that apply to the functional bindings of call-next-method or next-method-p apply to references to those functions within the method body forms. Any outer bindings of the function names call-next-method and next-method-p, and declarations associated with such bindings are shadowed[2] within the method body forms.»
This was decided in committee issue DEFMETHOD-
But in SBCL:
(defmethod foo (a) (declare (notinline call-next-method next-method-p)) (call-next-method (next-method-p)))
; in: DEFMETHOD FOO (T)
; (NOTINLINE CALL-NEXT-METHOD NEXT-METHOD-P)
;
; caught WARNING:
; The function CALL-NEXT-METHOD is undefined, and its name is reserved by ANSI CL
; so that even if it were defined later, the code doing so would not be portable.
;
; caught WARNING:
; The function NEXT-METHOD-P is undefined, and its name is reserved by ANSI CL so
; that even if it were defined later, the code doing so would not be portable.
;
; compilation unit finished
; Undefined functions:
; CALL-NEXT-METHOD NEXT-METHOD-P
; caught 2 WARNING conditions
STYLE-WARNING:
Implicitly creating new generic function COMMON-
#<STANDARD-METHOD FOO (T) {FB365C1}>
Modern PCL apparently moves the declaration up past the flet for call-next-method:
(SB-PCL:
(DECLARE (TYPE T A))
and so on.
This is a minor issue [even if someone actually ran into it, a few well-placed #-sbcl s would kill the warnings and not alter the semantics noticeably] and probably somewhat difficult to fix, given all the code walking PCL does, but I thought I should report it if only so that it's known.
Changed in sbcl: | |
status: | New → Triaged |
importance: | Undecided → Low |
tags: | added: pcl |