Cannot find type for specializer #:G0

Bug #1761947 reported by Michał "phoe" Herda
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
New
Undecided
Unassigned

Bug Description

(unwind-protect
     (progn (defclass #1=#.(gensym) () ())
            (defmethod initialize-instance :before ((object #1#) &key)))
  (setf (find-class '#1#) nil))

On SBCL 1.4.4 evaluating this causes a warning to be emitted:

; file: /tmp/slime9rrJ50
; in: DEFMETHOD INITIALIZE-INSTANCE
; (CLOSER-MOP:DEFMETHOD INITIALIZE-INSTANCE
; :BEFORE
; ((PROTEST/BASE::OBJECT #:G0) &KEY))
; --> DEFMETHOD PROGN EVAL-WHEN
; ==>
; (SB-PCL::%DEFMETHOD-EXPANDER INITIALIZE-INSTANCE (:BEFORE)
; ((PROTEST/BASE::OBJECT #:G0) &KEY) NIL)
;
; caught STYLE-WARNING:
; Cannot find type for specializer #:G0 when executing
; SB-PCL:SPECIALIZER-TYPE-SPECIFIER for a STANDARD-METHOD of a
; STANDARD-GENERIC-FUNCTION.
;
; compilation unit finished
; caught 1 STYLE-WARNING condition

Revision history for this message
Douglas Katzman (dougk) wrote :

The macroexpander of DEFMETHOD is to blame, but this could be considered just an unfortunate side-effect of *EVALUATOR-MODE* being set to :COMPILE, which makes the entire form a single lambda. As such, the defmethod expander warns before the DEFCLASS is executed. Some potential fixes:

 - get the macro to inject the WARN call into the :COMPILE-TOPLEVEL effects of its expansion so that it will only warn from COMPILE-FILE

 - remove the warning generation from the macro, but put a compiler-macro on LOAD-DEFMETHOD that warns if any of the classes named in its 4th argument - which should always have the form (LIST (FIND-CLASS 'thing) ...) - aren't known.
   This is similar to using vacuous transforms as we do to detect misshapen FORMAT strings.

 - just remove the warning entirely. this is really taking the low road

 - don't set *EVALUATOR-MODE* to :COMPILE

 - turn this warning into a deferrable warning (patch attached)

Revision history for this message
Douglas Katzman (dougk) wrote :

This adds a compilation-unit around LOAD which I think we should do anyway.

Revision history for this message
Michał "phoe" Herda (phoe-krk) wrote :

This is still present as of 1.4.14.

Revision history for this message
Michał "phoe" Herda (phoe-krk) wrote :

Still present on 2.0.1.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.