CLOS: Long instructions cause errors

[slburson]

Describe the bug
To reproduce:

> (ql:quickload "fset")
> (in-package :fset)
> (run-test-suite 32)

Result: some "Dealing with long instruction" messages, and then an error (see below).

Expected behavior
The test should pass, or at least fail for a more intelligible reason.

Actual behavior

#(CLOS::BC-INSTRUCTION "effective-method-outcome" 4117 1770 NIL
  12 NIL CLOS::BC-LONG-INSTRUCTION 21) is not of type CONS.

Backtrace:
  0: ERROR
  1: (CLOS::GENERATE-LABEL-MAP ((#(CLOS::BC-INSTRUCTION "farg0" 0 0 NIL 13 ...)) (#(CLOS::BC-INSTRUCTION "eql" 1 1 NIL 7 ...) #(CLOS::BC-CONSTANT-REF 0) #(CLOS::BC-LABEL-ARG 4079 1755 NIL)) ..) #(NIL NIL N..
  2: (LAMBDA (&OPTIONAL CLOS::INSTRUCTIONS CLOS::LITERALS CLOS::LONGS &REST #:G76731))
  3: (LAMBDA (&OPTIONAL CLOS::COMPILED CLOS::SPECIALIZED-LENGTH &REST #:G76728))
  4: (CLOS:BYTECODE-DTREE-COMPILE #<STANDARD-GENERIC-FUNCTION CONVERT>)
  5: (CLOS::BYTECODE-INTERPRETED-DISCRIMINATOR #<STANDARD-GENERIC-FUNCTION CONVERT>)
  6: (CLOS::CALCULATE-FASTGF-DISPATCH-FUNCTION #<STANDARD-GENERIC-FUNCTION CONVERT>)
  7: (CLOS::FORCE-DISPATCHER #<STANDARD-GENERIC-FUNCTION CONVERT>)
  8: ((METHOD CONVERT ((EQL 'CH-REPLAY-MAP) CH-REPLAY-MAP)) CH-REPLAY-MAP ##{=| (19 FOO) (12 BAR) (8 QUUX) (2 GUBBISH) (34 ORK) |}/XYZZY :KEY-COMPARE-FN-NAME ERAPMOC :VAL-COMPARE-FN-NAME EQL-COMPARE)
  9: (TEST-MISC-3)
 10: (RUN-TEST-SUITE 32)

Code at issue

(defmethod convert ((to-type (eql 'ch-replay-map)) (m ch-replay-map)
		    &key (default nil default?) key-compare-fn-name val-compare-fn-name)
  (let ((tm (convert 'map m))
	((cm (convert 'ch-map tm
		      :key-compare-fn-name key-compare-fn-name :val-compare-fn-name val-compare-fn-name))))
    (if (eq cm tm) m
      (make-ch-replay-map (ch-map-contents cm) (replay-map-ordering m) (ch-map-org cm)
			  (if default? default (map-default m))))))

I poked at the backtrace a little, and noticed that in clos::reference-literals, the elements of new-program for which long-arg is true are not lists: they're the result of longify-instruction. It doesn't look like this code ever worked. Not sure what could be unusual about the above method, except that it reinvokes its generic function on different arguments.

Context

• 2.7.0 on x86-64 Linux
• ((COMPILATION-SPEED 1) (DEBUG 1) (SPACE 1) (SPEED 1) (SAFETY 1))

[Bike]

There's probably nothing to do with that method in particular. The dtree interpreter (which involves reference-literals, etc.) is what takes care of method dispatch. The reason you're hitting the "long" code is that there's at least 256 of something (method specializations, maybe) so the usual bytecode limits are being reached. The "long" provisions let it go up to 65536, but as you say, they are not well tread.

I don't understand the long code myself so I'll have to dig some more.