X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=010c3b731394f8ff66b594b035e8991ca1d9e27c;hb=af141fe8d840aeb9011e3c6d2d6492216a12304c;hp=be258bd7aa0e7ad7977b06bd62e96625c0cc2ac7;hpb=56a55fd26733bb228e69f9c884baddd772308724;p=sbcl.git diff --git a/BUGS b/BUGS index be258bd..010c3b7 100644 --- a/BUGS +++ b/BUGS @@ -89,15 +89,6 @@ WORKAROUND: Perhaps any number of such consecutive lines ought to turn into a single "compiling top-level forms:" line. -11: - It would be nice if the - caught ERROR: - (during macroexpansion) - said what macroexpansion was at fault, e.g. - caught ERROR: - (during macroexpansion of IN-PACKAGE, - during macroexpansion of DEFFOO) - 19: (I *think* this is a bug. It certainly seems like strange behavior. But the ANSI spec is scary, dark, and deep.. -- WHN) @@ -113,9 +104,10 @@ WORKAROUND: 32: The printer doesn't report closures very well. This is true in CMU CL 18b as well: - (PRINT #'CLASS-NAME) + (defstruct foo bar) + (print #'foo-bar) gives - # + # It would be nice to make closures have a settable name slot, and make things like DEFSTRUCT and FLET, which create closures, set helpful values into this slot. @@ -165,34 +157,6 @@ WORKAROUND: so they could be supported after all. Very likely SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too. -45: - a slew of floating-point-related errors reported by Peter Van Eynde - on July 25, 2000: - c: Many expressions generate floating infinity on x86/Linux: - (/ 1 0.0) - (/ 1 0.0d0) - (EXPT 10.0 1000) - (EXPT 10.0d0 1000) - PVE's regression tests want them to raise errors. sbcl-0.7.0.5 - on x86/Linux generates the infinities instead. That might or - might not be conforming behavior, but it's also inconsistent, - which is almost certainly wrong. (Inconsistency: (/ 1 0.0) - should give the same result as (/ 1.0 0.0), but instead (/ 1 0.0) - generates SINGLE-FLOAT-POSITIVE-INFINITY and (/ 1.0 0.0) - signals an error. - d: (in section12.erg) various forms a la - (FLOAT 1 DOUBLE-FLOAT-EPSILON) - don't give the right behavior. - -46: - type safety errors reported by Peter Van Eynde July 25, 2000: - k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is - not a binary input stream, but instead cheerfully reads from - string-input streams, e.g. (MAKE-STRING-INPUT-STREAM "abc"). - [ Bug was reported as "from character streams", but in 0.8.3.10 we - get correct behaviour from (WITH-OPEN-FILE (i "/dev/zero") (READ-BYTE i)) ] - - 60: The debugger LIST-LOCATIONS command doesn't work properly. (How should it work properly?) @@ -204,6 +168,12 @@ WORKAROUND: then requesting a BACKTRACE at the debugger prompt gives no information about where in the user program the problem occurred. + (this is apparently mostly fixed on the SPARC, PPC, and x86 architectures: + while giving the backtrace the non-x86 systems complains about "unknown + source location: using block start", but apart from that the + backtrace seems reasonable. On x86 this is masked by bug 353. See + tests/debug.impure.lisp for a test case) + 64: Using the pretty-printer from the command prompt gives funny results, apparently because the pretty-printer doesn't know @@ -227,20 +197,6 @@ WORKAROUND: e-mail on cmucl-help@cons.org on 2001-01-16 and 2001-01-17 from WHN and Pierre Mai.) -79: - as pointed out by Dan Barlow on sbcl-devel 2000-07-02: - The PICK-TEMPORARY-FILE-NAME utility used by LOAD-FOREIGN uses - an easily guessable temporary filename in a way which might open - applications using LOAD-FOREIGN to hijacking by malicious users - on the same machine. Incantations for doing this safely are - floating around the net in various "how to write secure programs - despite Unix" documents, and it would be good to (1) fix this in - LOAD-FOREIGN, and (2) hunt for any other code which uses temporary - files and make it share the same new safe logic. - - (partially alleviated in sbcl-0.7.9.32 by a fix by Matthew Danish to - make the temporary filename less easily guessable) - 83: RANDOM-INTEGER-EXTRA-BITS=10 may not be large enough for the RANDOM RNG to be high quality near RANDOM-FIXNUM-MAX; it looks as though @@ -273,6 +229,11 @@ WORKAROUND: GC, so that thereafter memory usage can never be reduced below that level. + (As of 0.8.7.3 it's likely that the latter half of this bug is fixed. + The interaction between gencgc and the variables used by + save-lisp-and-die is still nonoptimal, though, so no respite from + big core files yet) + 98: In sbcl-0.6.11.41 (and in all earlier SBCL, and in CMU CL), out-of-line structure slot setters are horribly inefficient @@ -333,6 +294,15 @@ WORKAROUND: time trying to GC afterwards. Surely there's some more economical way to implement (ROOM T). + Daniel Barlow doesn't know what fixed this, but observes that it + doesn't seem to be the case in 0.8.7.3 any more. Instead, (ROOM T) + in a fresh SBCL causes + + debugger invoked on a SB-INT:BUG in thread 5911: + failed AVER: "(SAP= CURRENT END)" + + unless a GC has happened beforehand. + 117: When the compiler inline expands functions, it may be that different kinds of return values are generated from different code branches. @@ -363,28 +333,6 @@ WORKAROUND: (see also bug 279) -118: - as reported by Eric Marsden on cmucl-imp@cons.org 2001-08-14: - (= (FLOAT 1 DOUBLE-FLOAT-EPSILON) - (+ (FLOAT 1 DOUBLE-FLOAT-EPSILON) DOUBLE-FLOAT-EPSILON)) => T - when of course it should be NIL. (He says it only fails for X86, - not SPARC; dunno about Alpha.) - - Also, "the same problem exists for LONG-FLOAT-EPSILON, - DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON (though - for the -negative- the + is replaced by a - in the test)." - - Raymond Toy comments that this is tricky on the X86 since its FPU - uses 80-bit precision internally. - -120b: - Even in sbcl-0.pre7.x, which is supposed to be free of the old - non-ANSI behavior of treating the function return type inferred - from the current function definition as a declaration of the - return type from any function of that name, the return type of NIL - is attached to FOO in 120a above, and used to optimize code which - calls FOO. - 124: As of version 0.pre7.14, SBCL's implementation of MACROLET makes the entire lexical environment at the point of MACROLET available @@ -459,17 +407,6 @@ WORKAROUND: forever, even when it is uninterned and all other references to it are lost. -141: "pretty printing and backquote" - a. - * '``(FOO ,@',@S) - ``(FOO SB-IMPL::BACKQ-COMMA-AT S) - - b. - * (write '`(, .ala.) :readably t :pretty t) - `(,.ALA.) - - (note the space between the comma and the point) - 143: (reported by Jesse Bouwman 2001-10-24 through the unfortunately prominent SourceForge web/db bug tracking system, which is @@ -501,6 +438,10 @@ WORKAROUND: conformance problem, since seems hard to construct useful code where it matters.) + [ partially fixed by CSR in 0.8.17.17 because of a PFD ansi-tests + report that (COMPLEX RATIO) was failing; still failing on types of + the form (AND NUMBER (SATISFIES REALP) (SATISFIES ZEROP)). ] + b. (fixed in 0.8.3.43) 146: @@ -537,20 +478,6 @@ WORKAROUND: This is probably the same bug as 216 -167: - In sbcl-0.7.3.11, compiling the (illegal) code - (in-package :cl-user) - (defmethod prove ((uustk uustk)) - (zap ((frob () nil)) - (frob))) - gives the (not terribly clear) error message - ; caught ERROR: - ; (during macroexpansion of (DEFMETHOD PROVE ...)) - ; can't get template for (FROB NIL NIL) - The problem seems to be that the code walker used by the DEFMETHOD - macro is unhappy with the illegal syntax in the method body, and - is giving an unclear error message. - 173: The compiler sometimes tries to constant-fold expressions before it checks to see whether they can be reached. This can lead to @@ -621,12 +548,6 @@ WORKAROUND: The careful type of X is {2k} :-(. Is it really important to be able to work with unions of many intervals? -190: "PPC/Linux pipe? buffer? bug" - In sbcl-0.7.6, the run-program.test.sh test script sometimes hangs - on the PPC/Linux platform, waiting for a zombie env process. This - is a classic symptom of buffer filling and deadlock, but it seems - only sporadically reproducible. - 191: "Miscellaneous PCL deficiencies" (reported by Alexey Dejneka sbcl-devel 2002-08-04) a. DEFCLASS does not inform the compiler about generated @@ -646,8 +567,7 @@ WORKAROUND: classes). This means that at present erroneous attempts to use WITH-SLOTS and the like on classes with metaclass STRUCTURE-CLASS won't get the corresponding STYLE-WARNING. - c. the examples in CLHS 7.6.5.1 (regarding generic function lambda - lists and &KEY arguments) do not signal errors when they should. + c. (fixed in 0.8.4.23) 201: "Incautious type inference from compound types" a. (reported by APD sbcl-devel 2002-09-17) @@ -734,11 +654,6 @@ WORKAROUND: all of the arguments are circular is probably desireable). 213: "Sequence functions and type checking" - a. MAKE-SEQUENCE, COERCE, MERGE and CONCATENATE cannot deal with - various complicated, though recognizeable, CONS types [e.g. - (CONS * (CONS * NULL)) - which according to ANSI should be recognized] (and, in SAFETY 3 - code, should return a list of LENGTH 2 or signal an error) b. MAP, when given a type argument that is SUBTYPEP LIST, does not check that it will return a sequence of the given type. Fixing it along the same lines as the others (cf. work done around @@ -753,20 +668,6 @@ WORKAROUND: (INTEGERP (CAR (MAKE-SEQUENCE '(CONS INTEGER *) 2))) can erroneously return T. -214: - SBCL 0.6.12.43 fails to compile - - (locally - (declare (optimize (inhibit-warnings 0) (compilation-speed 2))) - (flet ((foo (&key (x :vx x-p)) (list x x-p))) - (foo 1 2))) - - or a more simple example: - - (locally - (declare (optimize (inhibit-warnings 0) (compilation-speed 2))) - (lambda (x) (declare (fixnum x)) (if (< x 0) 0 (1- x)))) - 215: ":TEST-NOT handling by functions" a. FIND and POSITION currently signal errors when given non-NIL for both their :TEST and (deprecated) :TEST-NOT arguments, but by @@ -878,18 +779,6 @@ WORKAROUND: ; compilation unit finished ; printed 1 note -241: "DEFCLASS mysteriously remembers uninterned accessor names." - (from tonyms on #lisp IRC 2003-02-25) - In sbcl-0.7.12.55, typing - (defclass foo () ((bar :accessor foo-bar))) - (profile foo-bar) - (unintern 'foo-bar) - (defclass foo () ((bar :accessor foo-bar))) - gives the error message - "#:FOO-BAR already names an ordinary function or a macro." - So it's somehow checking the uninterned old accessor name instead - of the new requested accessor name, which seems broken to me (WHN). - 242: "WRITE-SEQUENCE suboptimality" (observed from clx performance) In sbcl-0.7.13, WRITE-SEQUENCE of a sequence of type @@ -912,13 +801,8 @@ WORKAROUND: ; The variable Y is defined but never used. 245: bugs in disassembler - a. On X86 an immediate operand for IMUL is printed incorrectly. b. On X86 operand size prefix is not recognized. -248: "reporting errors in type specifier syntax" - (TYPEP 1 '(SYMBOL NIL)) says something about "unknown type - specifier". - 251: (defun foo (&key (a :x)) (declare (fixnum a)) @@ -981,38 +865,13 @@ WORKAROUND: b. The same for CSUBTYPEP. -261: - * (let () (list (the (values &optional fixnum) (eval '(values))))) - debugger invoked on condition of type TYPE-ERROR: - The value NIL is not of type FIXNUM. - 262: "yet another bug in inline expansion of local functions" - Compiler fails on - - (defun foo (x y) - (declare (integer x y)) - (+ (block nil - (flet ((xyz (u) - (declare (integer u)) - (if (> (1+ (the unsigned-byte u)) 0) - (+ 1 u) - (return (+ 38 (cos (/ u 78))))))) - (declare (inline xyz)) - (return-from foo - (* (funcall (eval #'xyz) x) - (if (> x 30) - (funcall (if (> x 5) #'xyz #'identity) - (+ x 13)) - 38))))) - (sin (* x y)))) - - Urgh... It's time to write IR1-copier. - -265: - SB-EXT:RUN-PROGRAM is currently non-functional on Linux/PPC; - attempting to use it leads to segmentation violations. This is - probably because of a bogus implementation of - os_restore_fp_control(). + During inline expansion of a local function Python can try to + reference optimized away objects (functions, variables, CTRANs from + tags and blocks), which later may lead to problems. Some of the + cases are worked around by forbidding expansion in such cases, but + the better way would be to reimplement inline expansion by copying + IR1 structures. 266: David Lichteblau provided (sbcl-devel 2003-06-01) a patch to fix @@ -1032,9 +891,6 @@ WORKAROUND: (list x y))) (funcall (eval #'foo) 1))) -269: - SCALE-FLOAT should accept any integer for its second argument. - 270: In the following function constraint propagator optimizes nothing: @@ -1075,14 +931,6 @@ WORKAROUND: (fixed in 0.8.2.51, but a test case would be good) -276: - (defmethod fee ((x fixnum)) - (setq x (/ x 2)) - x) - (fee 1) => type error - - (taken from CLOCC) - 278: a. (defun foo () @@ -1119,39 +967,6 @@ WORKAROUND: (see also bug 117) -280: bogus WARNING about duplicate function definition - In sbcl-0.8.3 and sbcl-0.8.1.47, if BS.MIN is defined inline, - e.g. by - (declaim (inline bs.min)) - (defun bs.min (bases) nil) - before compiling the file below, the compiler warns - Duplicate definition for BS.MIN found in one static - unit (usually a file). - when compiling - (declaim (special *minus* *plus* *stagnant*)) - (defun b.*.min (&optional (x () xp) (y () yp) &rest rest) - (bs.min avec)) - (define-compiler-macro b.*.min (&rest rest) - `(bs.min ,@rest)) - (defun afish-d-rbd (pd) - (if *stagnant* - (b.*.min (foo-d-rbd *stagnant*)) - (multiple-value-bind (reduce-fn initial-value) - (etypecase pd - (list (values #'bs.min 0)) - (vector (values #'bs.min *plus*))) - (let ((cv-ks (cv (kpd.ks pd)))) - (funcall reduce-fn d-rbds))))) - (defun bfish-d-rbd (pd) - (if *stagnant* - (b.*.min (foo-d-rbd *stagnant*)) - (multiple-value-bind (reduce-fn initial-value) - (etypecase pd - (list (values #'bs.min *minus*)) - (vector (values #'bs.min 0))) - (let ((cv-ks (cv (kpd.ks pd)))) - (funcall reduce-fn d-rbds))))) - 281: COMPUTE-EFFECTIVE-METHOD error signalling. (slightly obscured by a non-0 default value for SB-PCL::*MAX-EMF-PRECOMPUTE-METHODS*) @@ -1170,16 +985,6 @@ WORKAROUND: The issue seems to be that construction of a discriminating function calls COMPUTE-EFFECTIVE-METHOD with methods that are not all applicable. -282: "type checking in full calls" - In current (0.8.3.6) implementation a CAST in a full call argument - is not checked; but the continuation between the CAST and the - combination has the "checked" type and CAST performs unsafe - coercion; this may lead to errors: if FOO is declared to take a - FIXNUM, this code will produce garbage on a machine with 30-bit - fixnums: - - (foo (aref (the (array (unsigned-byte 32)) x))) - 283: Thread safety: libc functions There are places that we call unsafe-for-threading libc functions that we should find alternatives for, or put locks around. Known or @@ -1212,20 +1017,12 @@ WORKAROUND: this problem. 288: fundamental cross-compilation issues (from old UGLINESS file) - 288a: Using host floating point numbers to represent target - floating point numbers, or host characters to represent - target characters, is theoretically shaky. (The characters - are OK as long as the characters are in the ANSI-guaranteed - character set, though, so they aren't a real problem as - long as the sources don't need anything but that.) - 288b: The compiler still makes assumptions about cross-compilation-host - implementation of ANSI CL: - 288b1: Simple bit vectors are distinct from simple vectors (in - DEFINE-STORAGE-BASE and elsewhere). (Actually, I'm not *sure* - that things would really break if this weren't so, but I - strongly suspect that they would.) - 288b2: SINGLE-FLOAT is distinct from DOUBLE-FLOAT. (This is - in a sense just one aspect of bug 288a.) + Using host floating point numbers to represent target floating point + numbers, or host characters to represent target characters, is + theoretically shaky. (The characters are OK as long as the characters + are in the ANSI-guaranteed character set, though, so they aren't a + real problem as long as the sources don't need anything but that; + the floats are a real problem.) 289: "type checking and source-transforms" a. @@ -1256,44 +1053,909 @@ WORKAROUND: the control word; however, this clobbers any change the user might have made. -293: - From Paul Dietz: - - (defparameter *f1* - (compile nil '(LAMBDA (C) - (TRUNCATE (LOGORC1 -996082 C) -2)))) - - (defparameter *f2* - (compile nil '(LAMBDA (C) (DECLARE (NOTINLINE TRUNCATE)) - (TRUNCATE (LOGORC1 -996082 C) -2)))) - - (print (funcall *f1* 25337234)) ==> 13099002 - (print (funcall *f2* 25337234)) ==> -13099001 - -294: - From Paul Dietz: - - * (funcall (compile nil `(lambda (c) - (declare (optimize (speed 3)) - (type (integer 23062188 149459656) c)) - (mod c (min -2 0)))) - 95019853) - - debugger invoked on condition of type SB-INT:SIMPLE-PROGRAM-ERROR: - invalid number of arguments: 1 +296: + (reported by Adam Warner, sbcl-devel 2003-09-23) + + The --load toplevel argument does not perform any sanitization of its + argument. As a result, files with Lisp pathname pattern characters + (#\* or #\?, for instance) or quotation marks can cause the system + to perform arbitrary behaviour. + +297: + LOOP with non-constant arithmetic step clauses suffers from overzealous + type constraint: code of the form + (loop for d of-type double-float from 0d0 to 10d0 by x collect d) + compiles to a type restriction on X of (AND DOUBLE-FLOAT (REAL + (0))). However, an integral value of X should be legal, because + successive adds of integers to double-floats produces double-floats, + so none of the type restrictions in the code is violated. + +300: (reported by Peter Graves) Function PEEK-CHAR checks PEEK-TYPE + argument type only after having read a character. This is caused + with EXPLICIT-CHECK attribute in DEFKNOWN. The similar problem + exists with =, /=, <, >, <=, >=. They were fixed, but it is probably + less error prone to have EXPLICIT-CHECK be a local declaration, + being put into the definition, instead of an attribute being kept in + a separate file; maybe also put it into SB-EXT? + +301: ARRAY-SIMPLE-=-TYPE-METHOD breaks on corner cases which can arise + in NOTE-ASSUMED-TYPES + In sbcl-0.8.7.32, compiling the file + (defun foo (x y) + (declare (type integer x)) + (declare (type (vector (or hash-table bit)) y)) + (bletch 2 y)) + (defun bar (x y) + (declare (type integer x)) + (declare (type (simple-array base (2)) y)) + (bletch 1 y)) + gives the error + failed AVER: "(NOT (AND (NOT EQUALP) CERTAINP))" + +303: "nonlinear LVARs" (aka MISC.293) + (defun buu (x) + (multiple-value-call #'list + (block foo + (multiple-value-prog1 + (eval '(values :a :b :c)) + (catch 'bar + (if (> x 0) + (return-from foo + (eval `(if (> ,x 1) + 1 + (throw 'bar (values 3 4))))))))))) + + (BUU 1) returns garbage. + + The problem is that both EVALs sequentially write to the same LVAR. + +305: + (Reported by Dave Roberts.) + Local INLINE/NOTINLINE declaration removes local FTYPE declaration: + + (defun quux (x) + (declare (ftype (function () (integer 0 10)) fee) + (inline fee)) + (1+ (fee))) + + uses generic arithmetic with INLINE and fixnum without. + +306: "Imprecise unions of array types" + a.(defun foo (x) + (declare (optimize speed) + (type (or (array cons) (array vector)) x)) + (elt (aref x 0) 0)) + (foo #((0))) => TYPE-ERROR + + relatedly, + + b.(subtypep + 'array + `(or + ,@(loop for x across sb-vm:*specialized-array-element-type-properties* + collect `(array ,(sb-vm:saetp-specifier x))))) + => NIL, T (when it should be T, T) + +309: "Dubious values for implementation limits" + (reported by Bruno Haible sbcl-devel "Incorrect value of + multiple-values-limit" 2004-04-19) + (values-list (make-list 1000000)), on x86/linux, signals a stack + exhaustion condition, despite MULTIPLE-VALUES-LIMIT being + significantly larger than 1000000. There are probably similar + dubious values for CALL-ARGUMENTS-LIMIT (see cmucl-help/cmucl-imp + around the same time regarding a call to LIST on sparc with 1000 + arguments) and other implementation limit constants. + +311: "Tokeniser not thread-safe" + (see also Robert Marlow sbcl-help "Multi threaded read chucking a + spak" 2004-04-19) + The tokenizer's use of *read-buffer* and *read-buffer-length* causes + spurious errors should two threads attempt to tokenise at the same + time. + +314: "LOOP :INITIALLY clauses and scope of initializers" + reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP + test suite, originally by Thomas F. Burdick. + ;; + ;; According to the HyperSpec 6.1.2.1.4, in for-as-equals-then, var is + ;; initialized to the result of evaluating form1. 6.1.7.2 says that + ;; initially clauses are evaluated in the loop prologue, which precedes all + ;; loop code except for the initial settings provided by with, for, or as. + (loop :for x = 0 :then (1+ x) + :for y = (1+ x) :then (ash y 1) + :for z :across #(1 3 9 27 81 243) + :for w = (+ x y z) + :initially (assert (zerop x)) :initially (assert (= 2 w)) + :until (>= w 100) :collect w) + Expected: (2 6 15 38) + Got: ERROR + +317: "FORMAT of floating point numbers" + reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP + test suite. + (format nil "~1F" 10) => "0." ; "10." expected + (format nil "~0F" 10) => "0." ; "10." expected + (format nil "~2F" 1234567.1) => "1000000." ; "1234567." expected + it would be nice if whatever fixed this also untangled the two + competing implementations of floating point printing (Steele and + White, and Burger and Dybvig) present in src/code/print.lisp + +318: "stack overflow in compiler warning with redefined class" + reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP + test suite. + (defstruct foo a) + (setf (find-class 'foo) nil) + (defstruct foo slot-1) + This used to give a stack overflow from within the printer, which has + been fixed as of 0.8.16.11. Current result: + ; caught ERROR: + ; can't compile TYPEP of anonymous or undefined class: + ; # + ... + debugger invoked on a TYPE-ERROR in thread 19973: + The value NIL is not of type FUNCTION. - [...] + CSR notes: it's not really clear what it should give: is (SETF FIND-CLASS) + meant to be enough to delete structure classes from the system? - * (funcall (compile nil `(lambda (b) - (declare (optimize (speed 3)) - (type (integer 2 152044363) b)) - (rem b (min -16 0)))) - 108251912) +319: "backquote with comma inside array" + reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP + test suite. + (read-from-string "`#1A(1 2 ,(+ 2 2) 4)") + gives + #(1 2 ((SB-IMPL::|,|) + 2 2) 4) + which probably isn't intentional. - debugger invoked on condition of type SB-INT:SIMPLE-PROGRAM-ERROR: - invalid number of arguments: 1 +323: "REPLACE, BIT-BASH and large strings" + The transform for REPLACE on simple-base-strings uses BIT-BASH, which + at present has an upper limit in size. Consequently, in sbcl-0.8.10 + (defun foo () + (declare (optimize speed (safety 1))) + (let ((x (make-string 140000000)) + (y (make-string 140000000))) + (length (replace x y)))) + (foo) + gives + debugger invoked on a TYPE-ERROR in thread 2412: + The value 1120000000 is not of type (MOD 536870911). + (see also "more and better sequence transforms" sbcl-devel 2004-05-10) + +324: "STREAMs and :ELEMENT-TYPE with large bytesize" + In theory, (open foo :element-type '(unsigned-byte )) should work + for all positive integral . At present, it only works for up + to about 1024 (and similarly for signed-byte), so + (open "/dev/zero" :element-type '(unsigned-byte 1025)) + gives an error in sbcl-0.8.10. + +325: "CLOSE :ABORT T on supeseding streams" + Closing a stream opened with :IF-EXISTS :SUPERSEDE with :ABORT T leaves no + file on disk, even if one existed before opening. + + The illegality of this is not crystal clear, as the ANSI dictionary + entry for CLOSE says that when :ABORT is T superseded files are not + superseded (ie. the original should be restored), whereas the OPEN + entry says about :IF-EXISTS :SUPERSEDE "If possible, the + implementation should not destroy the old file until the new stream + is closed." -- implying that even though undesirable, early deletion + is legal. Restoring the original would none the less be the polite + thing to do. + +326: "*PRINT-CIRCLE* crosstalk between streams" + In sbcl-0.8.10.48 it's possible for *PRINT-CIRCLE* references to be + mixed between streams when output operations are intermingled closely + enough (as by doing output on S2 from within (PRINT-OBJECT X S1) in the + test case below), so that e.g. the references #2# appears on a stream + with no preceding #2= on that stream to define it (because the #2= was + sent to another stream). + (cl:in-package :cl-user) + (defstruct foo index) + (defparameter *foo* (make-foo :index 4)) + (defstruct bar) + (defparameter *bar* (make-bar)) + (defparameter *tangle* (list *foo* *bar* *foo*)) + (defmethod print-object ((foo foo) stream) + (let ((index (foo-index foo))) + (format *trace-output* + "~&-$- emitting FOO ~D, ambient *BAR*=~S~%" + index *bar*) + (format stream "[FOO ~D]" index)) + foo) + (let ((tsos (make-string-output-stream)) + (ssos (make-string-output-stream))) + (let ((*print-circle* t) + (*trace-output* tsos) + (*standard-output* ssos)) + (prin1 *tangle* *standard-output*)) + (let ((string (get-output-stream-string ssos))) + (unless (string= string "(#1=[FOO 4] #S(BAR) #1#)") + ;; In sbcl-0.8.10.48 STRING was "(#1=[FOO 4] #2# #1#)".:-( + (error "oops: ~S" string))))) + It might be straightforward to fix this by turning the + *CIRCULARITY-HASH-TABLE* and *CIRCULARITY-COUNTER* variables into + per-stream slots, but (1) it would probably be sort of messy faking + up the special variable binding semantics using UNWIND-PROTECT and + (2) it might be sort of a pain to test that no other bugs had been + introduced. + +328: "Profiling generic functions", transplanted from #241 + (from tonyms on #lisp IRC 2003-02-25) + In sbcl-0.7.12.55, typing + (defclass foo () ((bar :accessor foo-bar))) + (profile foo-bar) + (unintern 'foo-bar) + (defclass foo () ((bar :accessor foo-bar))) + gives the error message + "#:FOO-BAR already names an ordinary function or a macro." -295: - From Paul Dietz: + Problem: when a generic function is profiled, it appears as an ordinary + function to PCL. (Remembering the uninterned accessor is OK, as the + redefinition must be able to remove old accessors from their generic + functions.) + +329: "Sequential class redefinition" + reported by Bruno Haible: + (defclass reactor () ((max-temp :initform 10000000))) + (defvar *r1* (make-instance 'reactor)) + (defvar *r2* (make-instance 'reactor)) + (slot-value *r1* 'max-temp) + (slot-value *r2* 'max-temp) + (defclass reactor () ((uptime :initform 0))) + (slot-value *r1* 'uptime) + (defclass reactor () ((uptime :initform 0) (max-temp :initform 10000))) + (slot-value *r1* 'max-temp) ; => 10000 + (slot-value *r2* 'max-temp) ; => 10000000 oops... + + Possible solution: + The method effective when the wrapper is obsoleted can be saved + in the wrapper, and then to update the instance just run through + all the old wrappers in order from oldest to newest. + +332: "fasl stack inconsistency in structure redefinition" + (reported by Tim Daly Jr sbcl-devel 2004-05-06) + Even though structure redefinition is undefined by the standard, the + following behaviour is suboptimal: running + (defun stimulate-sbcl () + (let ((filename (format nil "/tmp/~A.lisp" (gensym)))) + ;;create a file which redefines a structure incompatibly + (with-open-file (f filename :direction :output :if-exists :supersede) + (print '(defstruct astruct foo) f) + (print '(defstruct astruct foo bar) f)) + ;;compile and load the file, then invoke the continue restart on + ;;the structure redefinition error + (handler-bind ((error (lambda (c) (continue c)))) + (load (compile-file filename))))) + (stimulate-sbcl) + and choosing the CONTINUE restart yields the message + debugger invoked on a SB-INT:BUG in thread 27726: + fasl stack not empty when it should be + +336: "slot-definitions must retain the generic functions of accessors" + reported by Tony Martinez: + (defclass foo () ((bar :reader foo-bar))) + (defun foo-bar (x) x) + (defclass foo () ((bar :reader get-bar))) ; => error, should work + + Note: just punting the accessor removal if the fdefinition + is not a generic function is not enough: + + (defclass foo () ((bar :reader foo-bar))) + (defvar *reader* #'foo-bar) + (defun foo-bar (x) x) + (defclass foo () ((bar :initform 'ok :reader get-bar))) + (funcall *reader* (make-instance 'foo)) ; should be an error, since + ; the method must be removed + ; by the class redefinition + + Fixing this should also fix a subset of #328 -- update the + description with a new test-case then. + +337: MAKE-METHOD and user-defined method classes + (reported by Bruno Haible sbcl-devel 2004-06-11) + + In the presence of + +(defclass user-method (standard-method) (myslot)) +(defmacro def-user-method (name &rest rest) + (let* ((lambdalist-position (position-if #'listp rest)) + (qualifiers (subseq rest 0 lambdalist-position)) + (lambdalist (elt rest lambdalist-position)) + (body (subseq rest (+ lambdalist-position 1))) + (required-part + (subseq lambdalist 0 (or + (position-if + (lambda (x) (member x lambda-list-keywords)) + lambdalist) + (length lambdalist)))) + (specializers (mapcar #'find-class + (mapcar (lambda (x) (if (consp x) (second x) t)) + required-part))) + (unspecialized-required-part + (mapcar (lambda (x) (if (consp x) (first x) x)) required-part)) + (unspecialized-lambdalist + (append unspecialized-required-part + (subseq lambdalist (length required-part))))) + `(PROGN + (ADD-METHOD #',name + (MAKE-INSTANCE 'USER-METHOD + :QUALIFIERS ',qualifiers + :LAMBDA-LIST ',unspecialized-lambdalist + :SPECIALIZERS ',specializers + :FUNCTION + (LAMBDA (ARGUMENTS NEXT-METHODS-LIST) + (FLET ((NEXT-METHOD-P () NEXT-METHODS-LIST) + (CALL-NEXT-METHOD (&REST NEW-ARGUMENTS) + (UNLESS NEW-ARGUMENTS (SETQ NEW-ARGUMENTS ARGUMENTS)) + (IF (NULL NEXT-METHODS-LIST) + (ERROR "no next method for arguments ~:S" ARGUMENTS) + (FUNCALL (SB-PCL:METHOD-FUNCTION + (FIRST NEXT-METHODS-LIST)) + NEW-ARGUMENTS (REST NEXT-METHODS-LIST))))) + (APPLY #'(LAMBDA ,unspecialized-lambdalist ,@body) ARGUMENTS))))) + ',name))) + + (progn + (defgeneric test-um03 (x)) + (defmethod test-um03 ((x integer)) + (list* 'integer x (not (null (next-method-p))) (call-next-method))) + (def-user-method test-um03 ((x rational)) + (list* 'rational x (not (null (next-method-p))) (call-next-method))) + (defmethod test-um03 ((x real)) + (list 'real x (not (null (next-method-p))))) + (test-um03 17)) + works, but + + a.(progn + (defgeneric test-um10 (x)) + (defmethod test-um10 ((x integer)) + (list* 'integer x (not (null (next-method-p))) (call-next-method))) + (defmethod test-um10 ((x rational)) + (list* 'rational x (not (null (next-method-p))) (call-next-method))) + (defmethod test-um10 ((x real)) + (list 'real x (not (null (next-method-p))))) + (defmethod test-um10 :after ((x real))) + (def-user-method test-um10 :around ((x integer)) + (list* 'around-integer x + (not (null (next-method-p))) (call-next-method))) + (defmethod test-um10 :around ((x rational)) + (list* 'around-rational x + (not (null (next-method-p))) (call-next-method))) + (defmethod test-um10 :around ((x real)) + (list* 'around-real x (not (null (next-method-p))) (call-next-method))) + (test-um10 17)) + fails with a type error, and + + b.(progn + (defgeneric test-um12 (x)) + (defmethod test-um12 ((x integer)) + (list* 'integer x (not (null (next-method-p))) (call-next-method))) + (defmethod test-um12 ((x rational)) + (list* 'rational x (not (null (next-method-p))) (call-next-method))) + (defmethod test-um12 ((x real)) + (list 'real x (not (null (next-method-p))))) + (defmethod test-um12 :after ((x real))) + (defmethod test-um12 :around ((x integer)) + (list* 'around-integer x + (not (null (next-method-p))) (call-next-method))) + (defmethod test-um12 :around ((x rational)) + (list* 'around-rational x + (not (null (next-method-p))) (call-next-method))) + (def-user-method test-um12 :around ((x real)) + (list* 'around-real x (not (null (next-method-p))) (call-next-method))) + (test-um12 17)) + fails with NO-APPLICABLE-METHOD. + +339: "DEFINE-METHOD-COMBINATION bugs" + (reported by Bruno Haible via the clisp test suite) + + a. Syntax checking laxity (should produce errors): + i. (define-method-combination foo :documentation :operator) + ii. (define-method-combination foo :documentation nil) + iii. (define-method-combination foo nil) + iv. (define-method-combination foo nil nil + (:arguments order &aux &key)) + v. (define-method-combination foo nil nil (:arguments &whole)) + vi. (define-method-combination foo nil nil (:generic-function)) + vii. (define-method-combination foo nil nil (:generic-function bar baz)) + viii. (define-method-combination foo nil nil (:generic-function (bar))) + ix. (define-method-combination foo nil ((3))) + x. (define-method-combination foo nil ((a))) + + b. define-method-combination arguments lambda list badness + i. &aux args are currently unsupported; + ii. default values of &optional and &key arguments are ignored; + iii. supplied-p variables for &optional and &key arguments are not + bound. + + c. qualifier matching incorrect + (progn + (define-method-combination mc27 () + ((normal ()) + (ignored (:ignore :unused))) + `(list 'result + ,@(mapcar #'(lambda (method) `(call-method ,method)) normal))) + (defgeneric test-mc27 (x) + (:method-combination mc27) + (:method :ignore ((x number)) (/ 0))) + (test-mc27 7)) + + should signal an invalid-method-error, as the :IGNORE (NUMBER) + method is applicable, and yet matches neither of the method group + qualifier patterns. + +341: PPRINT-LOGICAL-BLOCK / PPRINT-FILL / PPRINT-LINEAR sharing detection. + (from Paul Dietz' test suite) + + CLHS on PPRINT-LINEAR and PPRINT-FILL (and PPRINT-TABULAR, though + that's slightly different) states that these functions perform + circular and shared structure detection on their object. Therefore, + + a.(let ((*print-circle* t)) + (pprint-linear *standard-output* (let ((x '(a))) (list x x)))) + should print "(#1=(A) #1#)" + + b.(let ((*print-circle* t)) + (pprint-linear *standard-output* + (let ((x (cons nil nil))) (setf (cdr x) x) x))) + should print "#1=(NIL . #1#)" + + (it is likely that the fault lies in PPRINT-LOGICAL-BLOCK, as + suggested by the suggested implementation of PPRINT-TABULAR) + +343: MOP:COMPUTE-DISCRIMINATING-FUNCTION overriding causes error + Even the simplest possible overriding of + COMPUTE-DISCRIMINATING-FUNCTION, suggested in the PCL implementation + as "canonical", does not work: + (defclass my-generic-function (standard-generic-function) () + (:metaclass funcallable-standard-class)) + (defmethod compute-discriminating-function ((gf my-generic-function)) + (let ((dfun (call-next-method))) + (lambda (&rest args) + (apply dfun args)))) + (defgeneric foo (x) + (:generic-function-class my-generic-function)) + (defmethod foo (x) (+ x x)) + (foo 5) + signals an error. This error is the same even if the LAMBDA is + replaced by (FUNCTION (SB-KERNEL:INSTANCE-LAMBDA ...)). Maybe the + SET-FUNCALLABLE-INSTANCE-FUN scary stuff in + src/code/target-defstruct.lisp is broken? This seems to be broken + in CMUCL 18e, so it's not caused by a recent change. + +344: more (?) ROOM T problems (possibly part of bug 108) + In sbcl-0.8.12.51, and off and on leading up to it, the + SB!VM:MEMORY-USAGE operations in ROOM T caused + unhandled condition (of type SB-INT:BUG): + failed AVER: "(SAP= CURRENT END)" + Several clever people have taken a shot at this without fixing + it; this time around (before sbcl-0.8.13 release) I (WHN) just + commented out the SB!VM:MEMORY-USAGE calls until someone figures + out how to make them work reliably with the rest of the GC. + + (Note: there's at least one dubious thing in room.lisp: see the + comment in VALID-OBJ) + +346: alpha backtrace + In sbcl-0.8.13, all backtraces from errors caused by internal errors + on the alpha seem to have a "bogus stack frame". + +349: PPRINT-INDENT rounding implementation decisions + At present, pprint-indent (and indeed the whole pretty printer) + more-or-less assumes that it's using a monospace font. That's + probably not too silly an assumption, but one piece of information + the current implementation loses is from requests to indent by a + non-integral amount. As of sbcl-0.8.15.9, the system silently + truncates the indentation to an integer at the point of request, but + maybe the non-integral value should be propagated through the + pprinter and only truncated at output? (So that indenting by 1/2 + then 3/2 would indent by two spaces, not one?) + +352: forward-referenced-class trouble + reported by Bruno Haible on sbcl-devel + (defclass c (a) ()) + (setf (class-name (find-class 'a)) 'b) + (defclass a () (x)) + (defclass b () (y)) + (make-instance 'c) + Expected: an instance of c, with a slot named x + Got: debugger invoked on a SIMPLE-ERROR in thread 78906: + While computing the class precedence list of the class named C. + The class named B is a forward referenced class. + The class named B is a direct superclass of the class named C. + +353: debugger suboptimalities on x86 + On x86 backtraces for undefined functions start with a bogus stack + frame, and backtraces for throws to unknown catch tags with a "no + debug information" frame. These are both due to CODE-COMPONENT-FROM-BITS + (used on non-x86 platforms) being a more complete solution then what + is done on x86. + + More generally, the debugger internals suffer from excessive x86/non-x86 + conditionalization and OAOOMization: refactoring the common parts would + be good. + +354: XEPs in backtraces + Under default compilation policy + (defun test () + (throw :unknown t)) + (test) + Has the XEP for TEST in the backtrace, not the TEST frame itself. + (sparc and x86 at least) + +355: change-class of generic-function + (reported by Bruno Haible) + The MOP doesn't support change-class on a generic-function. However, SBCL + apparently supports it, since it doesn't give an error or warning when doing + so so. Then, however, it produces wrong results for calls to this generic + function. + ;;; The effective-methods cache: + (progn + (defgeneric testgf35 (x)) + (defmethod testgf35 ((x integer)) + (cons 'integer (if (next-method-p) (call-next-method)))) + (defmethod testgf35 ((x real)) + (cons 'real (if (next-method-p) (call-next-method)))) + (defclass customized5-generic-function (standard-generic-function) + () + (:metaclass sb-pcl:funcallable-standard-class)) + (defmethod sb-pcl:compute-effective-method ((gf customized5-generic-function) method-combination methods) + `(REVERSE ,(call-next-method))) + (list + (testgf35 3) + (progn + (change-class #'testgf35 'customized5-generic-function) + (testgf35 3)))) + Expected: ((INTEGER REAL) (REAL INTEGER)) + Got: ((INTEGER REAL) (INTEGER REAL)) + ;;; The discriminating-function cache: + (progn + (defgeneric testgf36 (x)) + (defmethod testgf36 ((x integer)) + (cons 'integer (if (next-method-p) (call-next-method)))) + (defmethod testgf36 ((x real)) + (cons 'real (if (next-method-p) (call-next-method)))) + (defclass customized6-generic-function (standard-generic-function) + () + (:metaclass sb-pcl:funcallable-standard-class)) + (defmethod sb-pcl:compute-discriminating-function ((gf customized6-generic-function)) + (let ((orig-df (call-next-method))) + #'(lambda (&rest arguments) + (reverse (apply orig-df arguments))))) + (list + (testgf36 3) + (progn + (change-class #'testgf36 'customized6-generic-function) + (testgf36 3)))) + Expected: ((INTEGER REAL) (REAL INTEGER)) + Got: ((INTEGER REAL) (INTEGER REAL)) + +356: PCL corruption + (reported by Bruno Haible) + After the "layout depth conflict" error, the CLOS is left in a state where + it's not possible to define new standard-class subclasses any more. + Test case: + (defclass prioritized-dispatcher () + ((dependents :type list :initform nil))) + (defmethod sb-pcl:validate-superclass ((c1 sb-pcl:funcallable-standard-class) + (c2 (eql (find-class 'prioritized-dispatcher)))) + t) + (defclass prioritized-generic-function (prioritized-dispatcher standard-generic-function) + () + (:metaclass sb-pcl:funcallable-standard-class)) + ;; ERROR, Quit the debugger with ABORT + (defclass typechecking-reader-class (standard-class) + ()) + Expected: # + Got: ERROR "The assertion SB-PCL::WRAPPERS failed." + +357: defstruct inheritance of initforms + (reported by Bruno Haible) + When defstruct and defclass (with :metaclass structure-class) are mixed, + 1. some slot initforms are ignored by the DEFSTRUCT generated constructor + function, and + 2. all slot initforms are ignored by MAKE-INSTANCE. (This can be arguably + OK for initforms that were given in a DEFSTRUCT form, but for those + given in a DEFCLASS form, I think it qualifies as a bug.) + Test case: + (defstruct structure02a + slot1 + (slot2 t) + (slot3 (floor pi))) + (defclass structure02b (structure02a) + ((slot4 :initform -44) + (slot5) + (slot6 :initform t) + (slot7 :initform (floor (* pi pi))) + (slot8 :initform 88)) + (:metaclass structure-class)) + (defstruct (structure02c (:include structure02b (slot8 -88))) + slot9 + (slot10 t) + (slot11 (floor (exp 3)))) + ;; 1. Form: + (let ((a (make-structure02c))) + (list (structure02c-slot4 a) + (structure02c-slot5 a) + (structure02c-slot6 a) + (structure02c-slot7 a))) + Expected: (-44 nil t 9) + Got: (SB-PCL::..SLOT-UNBOUND.. SB-PCL::..SLOT-UNBOUND.. + SB-PCL::..SLOT-UNBOUND.. SB-PCL::..SLOT-UNBOUND..) + ;; 2. Form: + (let ((b (make-instance 'structure02c))) + (list (structure02c-slot2 b) + (structure02c-slot3 b) + (structure02c-slot4 b) + (structure02c-slot6 b) + (structure02c-slot7 b) + (structure02c-slot8 b) + (structure02c-slot10 b) + (structure02c-slot11 b))) + Expected: (t 3 -44 t 9 -88 t 20) + Got: (0 0 0 0 0 0 0 0) + +358: :DECLARE argument to ENSURE-GENERIC-FUNCTION + (reported by Bruno Haible) + According to ANSI CL, ensure-generic-function must accept a :DECLARE + keyword argument. In SBCL 0.8.16 it does not. + Test case: + (progn + (ensure-generic-function 'foo113 :declare '((optimize (speed 3)))) + (sb-pcl:generic-function-declarations #'foo113)) + Expected: ((OPTIMIZE (SPEED 3))) + Got: ERROR + Invalid initialization argument: + :DECLARE + in call for class #. + See also: + The ANSI Standard, Section 7.1.2 + + Bruno notes: The MOP specifies that ensure-generic-function accepts :DECLARATIONS. + The easiest way to be compliant to both specs is to accept both (exclusively + or cumulatively). + +359: wrong default value for ensure-generic-function's :generic-function-class argument + (reported by Bruno Haible) + ANSI CL is silent on this, but the MOP's specification of ENSURE-GENERIC-FUNCTION says: + "The remaining arguments are the complete set of keyword arguments + received by ENSURE-GENERIC-FUNCTION." + and the spec of ENSURE-GENERIC-FUNCTION-USING-CLASS: + ":GENERIC-FUNCTION-CLASS - a class metaobject or a class name. If it is not + supplied, it defaults to the class named STANDARD-GENERIC-FUNCTION." + This is not the case in SBCL. Test case: + (defclass my-generic-function (standard-generic-function) + () + (:metaclass sb-pcl:funcallable-standard-class)) + (setf (fdefinition 'foo1) + (make-instance 'my-generic-function :name 'foo1)) + (ensure-generic-function 'foo1 + :generic-function-class (find-class 'standard-generic-function)) + (class-of #'foo1) + ; => # + (setf (fdefinition 'foo2) + (make-instance 'my-generic-function :name 'foo2)) + (ensure-generic-function 'foo2) + (class-of #'foo2) + Expected: # + Got: # + +360: CALL-METHOD not recognized in method-combination body + (reported by Bruno Haible) + This method combination, which adds 'redo' and 'return' restarts for each + method invocation to standard method combination, gives an error in SBCL. + (defun prompt-for-new-values () + (format *debug-io* "~&New values: ") + (list (read *debug-io*))) + (defun add-method-restarts (form method) + (let ((block (gensym)) + (tag (gensym))) + `(BLOCK ,block + (TAGBODY + ,tag + (RETURN-FROM ,block + (RESTART-CASE ,form + (METHOD-REDO () + :REPORT (LAMBDA (STREAM) (FORMAT STREAM "Try calling ~S again." ,method)) + (GO ,tag)) + (METHOD-RETURN (L) + :REPORT (LAMBDA (STREAM) (FORMAT STREAM "Specify return values for ~S call." ,method)) + :INTERACTIVE (LAMBDA () (PROMPT-FOR-NEW-VALUES)) + (RETURN-FROM ,block (VALUES-LIST L))))))))) + (defun convert-effective-method (efm) + (if (consp efm) + (if (eq (car efm) 'CALL-METHOD) + (let ((method-list (third efm))) + (if (or (typep (first method-list) 'method) (rest method-list)) + ; Reduce the case of multiple methods to a single one. + ; Make the call to the next-method explicit. + (convert-effective-method + `(CALL-METHOD ,(second efm) + ((MAKE-METHOD + (CALL-METHOD ,(first method-list) ,(rest method-list)))))) + ; Now the case of at most one method. + (if (typep (second efm) 'method) + ; Wrap the method call in a RESTART-CASE. + (add-method-restarts + (cons (convert-effective-method (car efm)) + (convert-effective-method (cdr efm))) + (second efm)) + ; Normal recursive processing. + (cons (convert-effective-method (car efm)) + (convert-effective-method (cdr efm)))))) + (cons (convert-effective-method (car efm)) + (convert-effective-method (cdr efm)))) + efm)) + (define-method-combination standard-with-restarts () + ((around (:around)) + (before (:before)) + (primary () :required t) + (after (:after))) + (flet ((call-methods-sequentially (methods) + (mapcar #'(lambda (method) + `(CALL-METHOD ,method)) + methods))) + (let ((form (if (or before after (rest primary)) + `(MULTIPLE-VALUE-PROG1 + (PROGN + ,@(call-methods-sequentially before) + (CALL-METHOD ,(first primary) ,(rest primary))) + ,@(call-methods-sequentially (reverse after))) + `(CALL-METHOD ,(first primary))))) + (when around + (setq form + `(CALL-METHOD ,(first around) + (,@(rest around) (MAKE-METHOD ,form))))) + (convert-effective-method form)))) + (defgeneric testgf16 (x) (:method-combination standard-with-restarts)) + (defclass testclass16a () ()) + (defclass testclass16b (testclass16a) ()) + (defclass testclass16c (testclass16a) ()) + (defclass testclass16d (testclass16b testclass16c) ()) + (defmethod testgf16 ((x testclass16a)) + (list 'a + (not (null (find-restart 'method-redo))) + (not (null (find-restart 'method-return))))) + (defmethod testgf16 ((x testclass16b)) + (cons 'b (call-next-method))) + (defmethod testgf16 ((x testclass16c)) + (cons 'c (call-next-method))) + (defmethod testgf16 ((x testclass16d)) + (cons 'd (call-next-method))) + (testgf16 (make-instance 'testclass16d)) + + Expected: (D B C A T T) + Got: ERROR CALL-METHOD outside of a effective method form + + This is a bug because ANSI CL HyperSpec/Body/locmac_call-m__make-method + says + "The macro call-method invokes the specified method, supplying it with + arguments and with definitions for call-next-method and for next-method-p. + If the invocation of call-method is lexically inside of a make-method, + the arguments are those that were supplied to that method. Otherwise + the arguments are those that were supplied to the generic function." + and the example uses nothing more than these two cases (as you can see by + doing (trace convert-effective-method)). + +361: initialize-instance of standard-reader-method ignores :function argument + (reported by Bruno Haible) + Pass a custom :function argument to initialize-instance of a + standard-reader-method instance, but it has no effect. + ;; Check that it's possible to define reader methods that do typechecking. + (progn + (defclass typechecking-reader-method (sb-pcl:standard-reader-method) + ()) + (defmethod initialize-instance ((method typechecking-reader-method) &rest initargs + &key slot-definition) + (let ((name (sb-pcl:slot-definition-name slot-definition)) + (type (sb-pcl:slot-definition-type slot-definition))) + (apply #'call-next-method method + :function #'(lambda (args next-methods) + (declare (ignore next-methods)) + (apply #'(lambda (instance) + (let ((value (slot-value instance name))) + (unless (typep value type) + (error "Slot ~S of ~S is not of type ~S: ~S" + name instance type value)) + value)) + args)) + initargs))) + (defclass typechecking-reader-class (standard-class) + ()) + (defmethod sb-pcl:validate-superclass ((c1 typechecking-reader-class) (c2 standard-class)) + t) + (defmethod reader-method-class ((class typechecking-reader-class) direct-slot &rest args) + (find-class 'typechecking-reader-method)) + (defclass testclass25 () + ((pair :type (cons symbol (cons symbol null)) :initarg :pair :accessor testclass25-pair)) + (:metaclass typechecking-reader-class)) + (macrolet ((succeeds (form) + `(not (nth-value 1 (ignore-errors ,form))))) + (let ((p (list 'abc 'def)) + (x (make-instance 'testclass25))) + (list (succeeds (make-instance 'testclass25 :pair '(seventeen 17))) + (succeeds (setf (testclass25-pair x) p)) + (succeeds (setf (second p) 456)) + (succeeds (testclass25-pair x)) + (succeeds (slot-value x 'pair)))))) + Expected: (t t t nil t) + Got: (t t t t t) + + (inspect (first (sb-pcl:generic-function-methods #'testclass25-pair))) + shows that the method was created with a FAST-FUNCTION slot but with a + FUNCTION slot of NIL. + +362: missing error when a slot-definition is created without a name + (reported by Bruno Haible) + The MOP says about slot-definition initialization: + "The :NAME argument is a slot name. An ERROR is SIGNALled if this argument + is not a symbol which can be used as a variable name. An ERROR is SIGNALled + if this argument is not supplied." + Test case: + (make-instance (find-class 'sb-pcl:standard-direct-slot-definition)) + Expected: ERROR + Got: # + +363: missing error when a slot-definition is created with a wrong documentation object + (reported by Bruno Haible) + The MOP says about slot-definition initialization: + "The :DOCUMENTATION argument is a STRING or NIL. An ERROR is SIGNALled + if it is not. This argument default to NIL during initialization." + Test case: + (make-instance (find-class 'sb-pcl:standard-direct-slot-definition) + :name 'foo + :documentation 'not-a-string) + Expected: ERROR + Got: # + +364: does not support class objects as specializer names + (reported by Bruno Haible) + According to ANSI CL 7.6.2, class objects are valid specializer names, + and "Parameter specializer names are used in macros intended as the + user-level interface (defmethod)". DEFMETHOD's syntax section doesn't + mention this possibility in the BNF for parameter-specializer-name; + however, this appears to be an editorial omission, since the CLHS + mentions issue CLASS-OBJECT-SPECIALIZER:AFFIRM as being approved + by X3J13. SBCL doesn't support it: + (defclass foo () ()) + (defmethod goo ((x #.(find-class 'foo))) x) + Expected: #)> + Got: ERROR "# is not a legal class name." + +365: mixin on generic-function subclass + (reported by Bruno Haible) + a mixin class + (defclass prioritized-dispatcher () + ((dependents :type list :initform nil))) + on a generic-function subclass: + (defclass prioritized-generic-function (prioritized-dispatcher standard-generic-function) + () + (:metaclass sb-pcl:funcallable-standard-class)) + SBCL gives an error on this, telling to define a method on SB-MOP:VALIDATE-SUPERCLASS. If done, + (defmethod sb-pcl:validate-superclass ((c1 sb-pcl:funcallable-standard-class) + (c2 (eql (find-class 'prioritized-dispatcher)))) + t) + then, however, + (defclass prioritized-generic-function (prioritized-dispatcher standard-generic-function) + () + (:metaclass sb-pcl:funcallable-standard-class)) + => debugger invoked on a SIMPLE-ERROR in thread 6687: + layout depth conflict: #(# ...) + + Further discussion on this: http://thread.gmane.org/gmane.lisp.steel-bank.general/491 + +366: cannot define two generic functions with user-defined class + (reported by Bruno Haible) + it is possible to define one generic function class and an instance + of it. But attempting to do the same thing again, in the same session, + leads to a "Control stack exhausted" error. Test case: + (defclass my-generic-function-1 (standard-generic-function) + () + (:metaclass sb-pcl:funcallable-standard-class)) + (defgeneric testgf-1 (x) (:generic-function-class my-generic-function-1) + (:method ((x integer)) (cons 'integer nil))) + (defclass my-generic-function-2 (standard-generic-function) + () + (:metaclass sb-pcl:funcallable-standard-class)) + (defgeneric testgf-2 (x) (:generic-function-class my-generic-function-2) + (:method ((x integer)) (cons 'integer nil))) + => SB-KERNEL::CONTROL-STACK-EXHAUSTED - (ash -1000000000000 -10000000000000000000) ==> 0 ;; should be -1