X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=1e2fde677249b27899cb85ff1a352abb172708d6;hb=HEAD;hp=7bbd84c02f1fc181458a205e7ccde7783ecadef1;hpb=0f807aea814ad6eddea7824675da1ed2ff9cba86;p=sbcl.git diff --git a/BUGS b/BUGS index 7bbd84c..1e2fde6 100644 --- a/BUGS +++ b/BUGS @@ -1,2105 +1,17 @@ -REPORTING BUGS +SBCL uses Launchpad to track bugs. The bug database is available at: -Bugs can be reported on the help mailing list - sbcl-help@lists.sourceforge.net -or on the development mailing list - sbcl-devel@lists.sourceforge.net + https://bugs.launchpad.net/sbcl -Please include enough information in a bug report that someone reading -it can reproduce the problem, i.e. don't write - Subject: apparent bug in PRINT-OBJECT (or *PRINT-LENGTH*?) - PRINT-OBJECT doesn't seem to work with *PRINT-LENGTH*. Is this a bug? -but instead - Subject: apparent bug in PRINT-OBJECT (or *PRINT-LENGTH*?) - In sbcl-1.2.3 running under OpenBSD 4.5 on my Alpha box, when - I compile and load the file - (DEFSTRUCT (FOO (:PRINT-OBJECT (LAMBDA (X Y) - (LET ((*PRINT-LENGTH* 4)) - (PRINT X Y))))) - X Y) - then at the command line type - (MAKE-FOO) - the program loops endlessly instead of printing the object. +Reporting bugs there requires registering at Launchpad. However, bugs +can also be reported on the mailing list sbcl-bugs, which is +moderated but does _not_ require subscribing. Simply send email to + sbcl-bugs@lists.sourceforge.net -NOTES: +and the bug will be checked and added to Launchpad by SBCL maintainers. -There is also some information on bugs in the manual page and -in the TODO file. Eventually more such information may move here. +Historical note: before Launchpad was adopted this file contained a +list of currently open bugs. If you run into an SBCL bug number in the +range 1-431 inclusive, it refers to that list. -The gaps in the number sequence belong to old bug descriptions which -have gone away (typically because they were fixed, but sometimes for -other reasons, e.g. because they were moved elsewhere). - - -2: - DEFSTRUCT almost certainly should overwrite the old LAYOUT information - instead of just punting when a contradictory structure definition - is loaded. As it is, if you redefine DEFSTRUCTs in a way which - changes their layout, you probably have to rebuild your entire - program, even if you know or guess enough about the internals of - SBCL to wager that this (undefined in ANSI) operation would be safe. - -3: "type checking of structure slots" - a: - ANSI specifies that a type mismatch in a structure slot - initialization value should not cause a warning. -WORKAROUND: - This one might not be fixed for a while because while we're big - believers in ANSI compatibility and all, (1) there's no obvious - simple way to do it (short of disabling all warnings for type - mismatches everywhere), and (2) there's a good portable - workaround, and (3) by their own reasoning, it looks as though - ANSI may have gotten it wrong. ANSI justifies this specification - by saying - The restriction against issuing a warning for type mismatches - between a slot-initform and the corresponding slot's :TYPE - option is necessary because a slot-initform must be specified - in order to specify slot options; in some cases, no suitable - default may exist. - However, in SBCL (as in CMU CL or, for that matter, any compiler - which really understands Common Lisp types) a suitable default - does exist, in all cases, because the compiler understands the - concept of functions which never return (i.e. has return type NIL). - Thus, as a portable workaround, you can use a call to some - known-never-to-return function as the default. E.g. - (DEFSTRUCT FOO - (BAR (ERROR "missing :BAR argument") - :TYPE SOME-TYPE-TOO-HAIRY-TO-CONSTRUCT-AN-INSTANCE-OF)) - or - (DECLAIM (FTYPE (FUNCTION () NIL) MISSING-ARG)) - (DEFUN REQUIRED-ARG () ; workaround for SBCL non-ANSI slot init typing - (ERROR "missing required argument")) - (DEFSTRUCT FOO - (BAR (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT) - (BLETCH (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT) - (N-REFS-SO-FAR 0 :TYPE (INTEGER 0))) - Such code should compile without complaint and work correctly either - on SBCL or on any other completely compliant Common Lisp system. - - b: &AUX argument in a boa-constructor without a default value means - "do not initilize this slot" and does not cause type error. But - an error may be signalled at read time and it would be good if - SBCL did it. - - d: (fixed in 0.8.1.5) - -27: - Sometimes (SB-EXT:QUIT) fails with - Argh! maximum interrupt nesting depth (4096) exceeded, exiting - Process inferior-lisp exited abnormally with code 1 - I haven't noticed a repeatable case of this yet. - -33: - And as long as we're wishing, it would be awfully nice if INSPECT could - also report on closures, telling about the values of the bound variables. - - Currently INSPECT and DESCRIBE do show the values, but showing the - names of the bindings would be even nicer. - -35: - The compiler assumes that any time a function of declared FTYPE - doesn't signal an error, its arguments were of the declared type. - E.g. compiling and loading - (DECLAIM (OPTIMIZE (SAFETY 3))) - (DEFUN FACTORIAL (X) (GAMMA (1+ X))) - (DEFUN GAMMA (X) X) - (DECLAIM (FTYPE (FUNCTION (UNSIGNED-BYTE)) FACTORIAL)) - (DEFUN FOO (X) - (COND ((> (FACTORIAL X) 1.0E6) - (FORMAT T "too big~%")) - ((INTEGERP X) - (FORMAT T "exactly ~S~%" (FACTORIAL X))) - (T - (FORMAT T "approximately ~S~%" (FACTORIAL X))))) - then executing - (FOO 1.5) - will cause the INTEGERP case to be selected, giving bogus output a la - exactly 2.5 - This violates the "declarations are assertions" principle. - According to the ANSI spec, in the section "System Class FUNCTION", - this is a case of "lying to the compiler", but the lying is done - by the code which calls FACTORIAL with non-UNSIGNED-BYTE arguments, - not by the unexpectedly general definition of FACTORIAL. In any case, - "declarations are assertions" means that lying to the compiler should - cause an error to be signalled, and should not cause a bogus - result to be returned. Thus, the compiler should not assume - that arbitrary functions check their argument types. (It might - make sense to add another flag (CHECKED?) to DEFKNOWN to - identify functions which *do* check their argument types.) - (Also, verify that the compiler handles declared function - return types as assertions.) - -42: - The definitions of SIGCONTEXT-FLOAT-REGISTER and - %SET-SIGCONTEXT-FLOAT-REGISTER in x86-vm.lisp say they're not - supported on FreeBSD because the floating point state is not saved, - but at least as of FreeBSD 4.0, the floating point state *is* saved, - so they could be supported after all. Very likely - SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too. - -61: - Compiling and loading - (DEFUN FAIL (X) (THROW 'FAIL-TAG X)) - (FAIL 12) - 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 - about user's command input, including the user's carriage return - that the user, and therefore the pretty-printer thinks that - the new output block should start indented 2 or more characters - rightward of the correct location. - -67: - As reported by Winton Davies on a CMU CL mailing list 2000-01-10, - and reported for SBCL by Martin Atzmueller 2000-10-20: (TRACE GETHASH) - crashes SBCL. In general tracing anything which is used in the - implementation of TRACE is likely to have the same problem. - -78: - ANSI says in one place that type declarations can be abbreviated even - when the type name is not a symbol, e.g. - (DECLAIM ((VECTOR T) *FOOVECTOR*)) - SBCL doesn't support this. But ANSI says in another place that this - isn't allowed. So it's not clear this is a bug after all. (See the - e-mail on cmucl-help@cons.org on 2001-01-16 and 2001-01-17 from WHN - and Pierre Mai.) - -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 - the mean of the distribution can be systematically O(0.1%) wrong. - Just increasing R-I-E-B is probably not a good solution, since - it would decrease efficiency more than is probably necessary. Perhaps - using some sort of accept/reject method would be better. - -85: - Internally the compiler sometimes evaluates - (sb-kernel:type/= (specifier-type '*) (specifier-type t)) - (I stumbled across this when I added an - (assert (not (eq type1 *wild-type*))) - in the NAMED :SIMPLE-= type method.) '* isn't really a type, and - in a type context should probably be translated to T, and so it's - probably wrong to ask whether it's equal to the T type and then (using - the EQ type comparison in the NAMED :SIMPLE-= type method) return NIL. - (I haven't tried to investigate this bug enough to guess whether - there might be any user-level symptoms.) - - In fact, the type system is likely to depend on this inequality not - holding... * is not equivalent to T in many cases, such as - (VECTOR *) /= (VECTOR T). - -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 - whenever the type of the slot is declared, because out-of-line - structure slot setters are implemented as closures to save space, - so the compiler doesn't compile the type test into code, but - instead just saves the type in a lexical closure and interprets it - at runtime. - To exercise the problem, compile and load - (cl:in-package :cl-user) - (defstruct foo - (bar (error "missing") :type bar)) - (defvar *foo*) - (defun wastrel1 (x) - (loop (setf (foo-bar *foo*) x))) - (defstruct bar) - (defvar *bar* (make-bar)) - (defvar *foo* (make-foo :bar *bar*)) - (defvar *setf-foo-bar* #'(setf foo-bar)) - (defun wastrel2 (x) - (loop (funcall *setf-foo-bar* x *foo*))) - then run (WASTREL1 *BAR*) or (WASTREL2 *BAR*), hit Ctrl-C, and - use BACKTRACE, to see it's spending all essentially all its time - in %TYPEP and VALUES-SPECIFIER-TYPE and so forth. - One possible solution would be simply to give up on - representing structure slot accessors as functions, and represent - them as macroexpansions instead. This can be inconvenient for users, - but it's not clear that it's worse than trying to help by expanding - into a horribly inefficient implementation. - As a workaround for the problem, #'(SETF FOO) expressions - can be replaced with (EFFICIENT-SETF-FUNCTION FOO), where -(defmacro efficient-setf-function (place-function-name) - (or #+sbcl (and (sb-int:info :function :accessor-for place-function-name) - ;; a workaround for the problem, encouraging the - ;; inline expansion of the structure accessor, so - ;; that the compiler can optimize its type test - (let ((new-value (gensym "NEW-VALUE-")) - (structure-value (gensym "STRUCTURE-VALUE-"))) - `(lambda (,new-value ,structure-value) - (setf (,place-function-name ,structure-value) - ,new-value)))) - ;; no problem, can just use the ordinary expansion - `(function (setf ,place-function-name)))) - -100: - There's apparently a bug in CEILING optimization which caused - Douglas Crosher to patch the CMU CL version. Martin Atzmueller - applied the patches to SBCL and they didn't seem to cause problems - (as reported sbcl-devel 2001-05-04). However, since the patches - modify nontrivial code which was apparently written incorrectly - the first time around, until regression tests are written I'm not - comfortable merging the patches in the CVS version of SBCL. - -108: - (TIME (ROOM T)) reports more than 200 Mbytes consed even for - a clean, just-started SBCL system. And it seems to be right: - (ROOM T) can bring a small computer to its knees for a *long* - 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. - E.g. an inline expansion of POSITION generates integer results - from one branch, and NIL results from another. When that inline - expansion is used in a context where only one of those results - is acceptable, e.g. - (defun foo (x) - (aref *a1* (position x *a2*))) - and the compiler can't prove that the unacceptable branch is - never taken, then bogus type mismatch warnings can be generated. - If you need to suppress the type mismatch warnings, you can - suppress the inline expansion, - (defun foo (x) - #+sbcl (declare (notinline position)) ; to suppress bug 117 bogowarnings - (aref *a1* (position x *a2*))) - or, sometimes, suppress them by declaring the result to be of an - appropriate type, - (defun foo (x) - (aref *a1* (the integer (position x *a2*)))) - - This is not a new compiler problem in 0.7.0, but the new compiler - transforms for FIND, POSITION, FIND-IF, and POSITION-IF make it - more conspicuous. If you don't need performance from these functions, - and the bogus warnings are a nuisance for you, you can return to - your pre-0.7.0 state of grace with - #+sbcl (declaim (notinline find position find-if position-if)) ; bug 117.. - - (see also bug 279) - -124: - As of version 0.pre7.14, SBCL's implementation of MACROLET makes - the entire lexical environment at the point of MACROLET available - in the bodies of the macroexpander functions. In particular, it - allows the function bodies (which run at compile time) to try to - access lexical variables (which are only defined at runtime). - It doesn't even issue a warning, which is bad. - - The SBCL behavior arguably conforms to the ANSI spec (since the - spec says that the behavior is undefined, ergo anything conforms). - However, it would be better to issue a compile-time error. - Unfortunately I (WHN) don't see any simple way to detect this - condition in order to issue such an error, so for the meantime - SBCL just does this weird broken "conforming" thing. - - The ANSI standard says, in the definition of the special operator - MACROLET, - The macro-expansion functions defined by MACROLET are defined - in the lexical environment in which the MACROLET form appears. - Declarations and MACROLET and SYMBOL-MACROLET definitions affect - the local macro definitions in a MACROLET, but the consequences - are undefined if the local macro definitions reference any - local variable or function bindings that are visible in that - lexical environment. - Then it seems to contradict itself by giving the example - (defun foo (x flag) - (macrolet ((fudge (z) - ;The parameters x and flag are not accessible - ; at this point; a reference to flag would be to - ; the global variable of that name. - ` (if flag (* ,z ,z) ,z))) - ;The parameters x and flag are accessible here. - (+ x - (fudge x) - (fudge (+ x 1))))) - The comment "a reference to flag would be to the global variable - of the same name" sounds like good behavior for the system to have. - but actual specification quoted above says that the actual behavior - is undefined. - - (Since 0.7.8.23 macroexpanders are defined in a restricted version - of the lexical environment, containing no lexical variables and - functions, which seems to conform to ANSI and CLtL2, but signalling - a STYLE-WARNING for references to variables similar to locals might - be a good thing.) - -135: - Ideally, uninterning a symbol would allow it, and its associated - FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However, - at least as of sbcl-0.7.0, this isn't the case. Information about - FDEFINITIONs and PROCLAIMed properties is stored in globaldb.lisp - essentially in ordinary (non-weak) hash tables keyed by symbols. - Thus, once a system has an entry in this system, it tends to live - forever, even when it is uninterned and all other references to it - are lost. - -143: - (reported by Jesse Bouwman 2001-10-24 through the unfortunately - prominent SourceForge web/db bug tracking system, which is - unfortunately not a reliable way to get a timely response from - the SBCL maintainers) - In the course of trying to build a test case for an - application error, I encountered this behavior: - If you start up sbcl, and then lay on CTRL-C for a - minute or two, the lisp process will eventually say: - %PRIMITIVE HALT called; the party is over. - and throw you into the monitor. If I start up lisp, - attach to the process with strace, and then do the same - (abusive) thing, I get instead: - access failure in heap page not marked as write-protected - and the monitor again. I don't know enough to have the - faintest idea of what is going on here. - This is with sbcl 6.12, uname -a reports: - Linux prep 2.2.19 #4 SMP Tue Apr 24 13:59:52 CDT 2001 i686 unknown - I (WHN) have verified that the same thing occurs on sbcl-0.pre7.141 - under OpenBSD 2.9 on my X86 laptop. Do be patient when you try it: - it took more than two minutes (but less than five) for me. - -145: - a. - ANSI allows types `(COMPLEX ,FOO) to use very hairy values for - FOO, e.g. (COMPLEX (AND REAL (SATISFIES ODDP))). The old CMU CL - COMPLEX implementation didn't deal with this, and hasn't been - upgraded to do so. (This doesn't seem to be a high priority - 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: - Floating point errors are reported poorly. E.g. on x86 OpenBSD - with sbcl-0.7.1, - * (expt 2.0 12777) - debugger invoked on condition of type SB-KERNEL:FLOATING-POINT-EXCEPTION: - An arithmetic error SB-KERNEL:FLOATING-POINT-EXCEPTION was signalled. - No traps are enabled? How can this be? - It should be possible to be much more specific (overflow, division - by zero, etc.) and of course the "How can this be?" should be fixable. - - See also bugs #45.c and #183 - -162: - (reported by Robert E. Brown 2002-04-16) - When a function is called with too few arguments, causing the - debugger to be entered, the uninitialized slots in the bad call frame - seem to cause GCish problems, being interpreted as tagged data even - though they're not. In particular, executing ROOM in the - debugger at that point causes AVER failures: - * (machine-type) - "X86" - * (lisp-implementation-version) - "0.7.2.12" - * (typep 10) - ... - 0] (room) - ... - failed AVER: "(SAP= CURRENT END)" - (Christophe Rhodes reports that this doesn't occur on the SPARC, which - isn't too surprising since there are many differences in stack - implementation and GC conservatism between the X86 and other ports.) - - This is probably the same bug as 216 - -173: - The compiler sometimes tries to constant-fold expressions before - it checks to see whether they can be reached. This can lead to - bogus warnings about errors in the constant folding, e.g. in code - like - (WHEN X - (WRITE-STRING (> X 0) "+" "0")) - compiled in a context where the compiler can prove that X is NIL, - and the compiler complains that (> X 0) causes a type error because - NIL isn't a valid argument to #'>. Until sbcl-0.7.4.10 or so this - caused a full WARNING, which made the bug really annoying because then - COMPILE and COMPILE-FILE returned FAILURE-P=T for perfectly legal - code. Since then the warning has been downgraded to STYLE-WARNING, - so it's still a bug but at least it's a little less annoying. - -183: "IEEE floating point issues" - Even where floating point handling is being dealt with relatively - well (as of sbcl-0.7.5, on sparc/sunos and alpha; see bug #146), the - accrued-exceptions and current-exceptions part of the fp control - word don't seem to bear much relation to reality. E.g. on - SPARC/SunOS: - * (/ 1.0 0.0) - - debugger invoked on condition of type DIVISION-BY-ZERO: - arithmetic error DIVISION-BY-ZERO signalled - 0] (sb-vm::get-floating-point-modes) - - (:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO) - :ROUNDING-MODE :NEAREST - :CURRENT-EXCEPTIONS NIL - :ACCRUED-EXCEPTIONS (:INEXACT) - :FAST-MODE NIL) - 0] abort - * (sb-vm::get-floating-point-modes) - (:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO) - :ROUNDING-MODE :NEAREST - :CURRENT-EXCEPTIONS (:INEXACT) - :ACCRUED-EXCEPTIONS (:INEXACT) - :FAST-MODE NIL) - -188: "compiler performance fiasco involving type inference and UNION-TYPE" - (time (compile - nil - '(lambda () - (declare (optimize (safety 3))) - (declare (optimize (compilation-speed 2))) - (declare (optimize (speed 1) (debug 1) (space 1))) - (let ((start 4)) - (declare (type (integer 0) start)) - (print (incf start 22)) - (print (incf start 26)) - (print (incf start 28))) - (let ((start 6)) - (declare (type (integer 0) start)) - (print (incf start 22)) - (print (incf start 26))) - (let ((start 10)) - (declare (type (integer 0) start)) - (print (incf start 22)) - (print (incf start 26)))))) - - This example could be solved with clever enough constraint - propagation or with SSA, but consider - - (let ((x 0)) - (loop (incf x 2))) - - The careful type of X is {2k} :-(. Is it really important to be - able to work with unions of many intervals? - -191: "Miscellaneous PCL deficiencies" - (reported by Alexey Dejneka sbcl-devel 2002-08-04) - a. DEFCLASS does not inform the compiler about generated - functions. Compiling a file with - (DEFCLASS A-CLASS () - ((A-CLASS-X))) - (DEFUN A-CLASS-X (A) - (WITH-SLOTS (A-CLASS-X) A - A-CLASS-X)) - results in a STYLE-WARNING: - undefined-function - SB-SLOT-ACCESSOR-NAME::|COMMON-LISP-USER A-CLASS-X slot READER| - - APD's fix for this was checked in to sbcl-0.7.6.20, but Pierre - Mai points out that the declamation of functions is in fact - incorrect in some cases (most notably for structure - 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. (fixed in 0.8.4.23) - -201: "Incautious type inference from compound types" - a. (reported by APD sbcl-devel 2002-09-17) - (DEFUN FOO (X) - (LET ((Y (CAR (THE (CONS INTEGER *) X)))) - (SETF (CAR X) NIL) - (FORMAT NIL "~S IS ~S, Y = ~S" - (CAR X) - (TYPECASE (CAR X) - (INTEGER 'INTEGER) - (T '(NOT INTEGER))) - Y))) - - (FOO ' (1 . 2)) => "NIL IS INTEGER, Y = 1" - - b. - * (defun foo (x) - (declare (type (array * (4 4)) x)) - (let ((y x)) - (setq x (make-array '(4 4))) - (adjust-array y '(3 5)) - (= (array-dimension y 0) (eval `(array-dimension ,y 0))))) - FOO - * (foo (make-array '(4 4) :adjustable t)) - NIL - -205: "environment issues in cross compiler" - (These bugs have no impact on user code, but should be fixed or - documented.) - a. Macroexpanders introduced with MACROLET are defined in the null - lexical environment. - b. The body of (EVAL-WHEN (:COMPILE-TOPLEVEL) ...) is evaluated in - the null lexical environment. - c. The cross-compiler cannot inline functions defined in a non-null - lexical environment. - -206: ":SB-FLUID feature broken" - (reported by Antonio Martinez-Shotton sbcl-devel 2002-10-07) - Enabling :SB-FLUID in the target-features list in sbcl-0.7.8 breaks - the build. - -207: "poorly distributed SXHASH results for compound data" - SBCL's SXHASH could probably try a little harder. ANSI: "the - intent is that an implementation should make a good-faith - effort to produce hash-codes that are well distributed - within the range of non-negative fixnums". But - (let ((hits (make-hash-table))) - (dotimes (i 16) - (dotimes (j 16) - (let* ((ij (cons i j)) - (newlist (push ij (gethash (sxhash ij) hits)))) - (when (cdr newlist) - (format t "~&collision: ~S~%" newlist)))))) - reports lots of collisions in sbcl-0.7.8. A stronger MIX function - would be an obvious way of fix. Maybe it would be acceptably efficient - to redo MIX using a lookup into a 256-entry s-box containing - 29-bit pseudorandom numbers? - -211: "keywords processing" - a. :ALLOW-OTHER-KEYS T should allow a function to receive an odd - number of keyword arguments. - -212: "Sequence functions and circular arguments" - COERCE, MERGE and CONCATENATE go into an infinite loop when given - circular arguments; it would be good for the user if they could be - given an error instead (ANSI 17.1.1 allows this behaviour on the part - of the implementation, as conforming code cannot give non-proper - sequences to these functions. MAP also has this problem (and - solution), though arguably the convenience of being able to do - (MAP 'LIST '+ FOO '#1=(1 . #1#)) - might be classed as more important (though signalling an error when - all of the arguments are circular is probably desireable). - -213: "Sequence functions and type checking" - 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 - sbcl-0.7.8.45) is possible, but doing so efficiently didn't look - entirely straightforward. - c. All of these functions will silently accept a type of the form - (CONS INTEGER *) - whether or not the return value is of this type. This is - probably permitted by ANSI (see "Exceptional Situations" under - ANSI MAKE-SEQUENCE), but the DERIVE-TYPE mechanism does not - know about this escape clause, so code of the form - (INTEGERP (CAR (MAKE-SEQUENCE '(CONS INTEGER *) 2))) - can erroneously return T. - -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 - ANSI 17.2 "the consequences are unspecified", which by ANSI 1.4.2 - means that the effect is "unpredictable but harmless". It's not - clear what that actually means; it may preclude conforming - implementations from signalling errors. - b. COUNT, REMOVE and the like give priority to a :TEST-NOT argument - when conflict occurs. As a quality of implementation issue, it - might be preferable to treat :TEST and :TEST-NOT as being in some - sense the same &KEY, and effectively take the first test function in - the argument list. - c. Again, a quality of implementation issue: it would be good to issue a - STYLE-WARNING at compile-time for calls with :TEST-NOT, and a - WARNING for calls with both :TEST and :TEST-NOT; possibly this - latter should be WARNed about at execute-time too. - -216: "debugger confused by frames with invalid number of arguments" - In sbcl-0.7.8.51, executing e.g. (VECTOR-PUSH-EXTEND T), BACKTRACE, Q - leaves the system confused, enough so that (QUIT) no longer works. - It's as though the process of working with the uninitialized slot in - the bad VECTOR-PUSH-EXTEND frame causes GC problems, though that may - not be the actual problem. (CMU CL 18c doesn't have problems with this.) - - This is probably the same bug as 162 - -217: "Bad type operations with FUNCTION types" - In sbcl.0.7.7: - - * (values-type-union (specifier-type '(function (base-char))) - (specifier-type '(function (integer)))) - - # - - It causes insertion of wrong type assertions into generated - code. E.g. - - (defun foo (x s) - (let ((f (etypecase x - (character #'write-char) - (integer #'write-byte)))) - (funcall f x s) - (etypecase x - (character (write-char x s)) - (integer (write-byte x s))))) - - Then (FOO #\1 *STANDARD-OUTPUT*) signals type error. - - (In 0.7.9.1 the result type is (FUNCTION * *), so Python does not - produce invalid code, but type checking is not accurate.) - -233: bugs in constraint propagation - b. - (declaim (optimize (speed 2) (safety 3))) - (defun foo (x y) - (if (typep (prog1 x (setq x y)) 'double-float) - (+ x 1d0) - (+ x 2))) - (foo 1d0 5) => segmentation violation - -235: "type system and inline expansion" - a. - (declaim (ftype (function (cons) number) acc)) - (declaim (inline acc)) - (defun acc (c) - (the number (car c))) - - (defun foo (x y) - (values (locally (declare (optimize (safety 0))) - (acc x)) - (locally (declare (optimize (safety 3))) - (acc y)))) - - (foo '(nil) '(t)) => NIL, T. - -237: "Environment arguments to type functions" - a. Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and - UPGRADED-COMPLEX-PART-TYPE now have an optional environment - argument, but they ignore it completely. This is almost - certainly not correct. - b. Also, the compiler's optimizers for TYPEP have not been informed - about the new argument; consequently, they will not transform - calls of the form (TYPEP 1 'INTEGER NIL), even though this is - just as optimizeable as (TYPEP 1 'INTEGER). - -238: "REPL compiler overenthusiasm for CLOS code" - From the REPL, - * (defclass foo () ()) - * (defmethod bar ((x foo) (foo foo)) (call-next-method)) - causes approximately 100 lines of code deletion notes. Some - discussion on this issue happened under the title 'Three "interesting" - bugs in PCL', resulting in a fix for this oververbosity from the - compiler proper; however, the problem persists in the interactor - because the notion of original source is not preserved: for the - compiler, the original source of the above expression is (DEFMETHOD - BAR ((X FOO) (FOO FOO)) (CALL-NEXT-METHOD)), while by the time the - compiler gets its hands on the code needing compilation from the REPL, - it has been macroexpanded several times. - - A symptom of the same underlying problem, reported by Tony Martinez: - * (handler-case - (with-input-from-string (*query-io* " no") - (yes-or-no-p)) - (simple-type-error () 'error)) - ; in: LAMBDA NIL - ; (SB-KERNEL:FLOAT-WAIT) - ; - ; note: deleting unreachable code - ; compilation unit finished - ; printed 1 note - -242: "WRITE-SEQUENCE suboptimality" - (observed from clx performance) - In sbcl-0.7.13, WRITE-SEQUENCE of a sequence of type - (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (*)) on a stream with element-type - (UNSIGNED-BYTE 8) will write to the stream one byte at a time, - rather than writing the sequence in one go, leading to severe - performance degradation. - As of sbcl-0.9.0.36, this is solved for fd-streams, so is less of a - problem in practice. (Fully fixing this would require adding a - ansi-stream-n-bout slot and associated methods to write a byte - sequence to ansi-stream, similar to the existing ansi-stream-sout - slot/functions.) - -243: "STYLE-WARNING overenthusiasm for unused variables" - (observed from clx compilation) - In sbcl-0.7.14, in the presence of the macros - (DEFMACRO FOO (X) `(BAR ,X)) - (DEFMACRO BAR (X) (DECLARE (IGNORABLE X)) 'NIL) - somewhat surprising style warnings are emitted for - (COMPILE NIL '(LAMBDA (Y) (FOO Y))): - ; in: LAMBDA (Y) - ; (LAMBDA (Y) (FOO Y)) - ; - ; caught STYLE-WARNING: - ; The variable Y is defined but never used. - -245: bugs in disassembler - b. On X86 operand size prefix is not recognized. - -251: - (defun foo (&key (a :x)) - (declare (fixnum a)) - a) - - does not cause a warning. (BTW: old SBCL issued a warning, but for a - function, which was never called!) - -256: - Compiler does not emit warnings for - - a. (lambda () (svref (make-array 8 :adjustable t) 1)) - - b. (lambda (x) - (list (let ((y (the real x))) - (unless (floatp y) (error "")) - y) - (integer-length x))) - - c. (lambda (x) - (declare (optimize (debug 0))) - (declare (type vector x)) - (list (fill-pointer x) - (svref x 1))) - -257: - Complex array type does not have corresponding type specifier. - - This is a problem because the compiler emits optimization notes when - you use a non-simple array, and without a type specifier for hairy - array types, there's no good way to tell it you're doing it - intentionally so that it should shut up and just compile the code. - - Another problem is confusing error message "asserted type ARRAY - conflicts with derived type (VALUES SIMPLE-VECTOR &OPTIONAL)" during - compiling (LAMBDA (V) (VALUES (SVREF V 0) (VECTOR-POP V))). - - The last problem is that when type assertions are converted to type - checks, types are represented with type specifiers, so we could lose - complex attribute. (Now this is probably not important, because - currently checks for complex arrays seem to be performed by - callees.) - -259: - (compile nil '(lambda () (aref (make-array 0) 0))) compiles without - warning. Analogous cases with the index and length being equal and - greater than 0 are warned for; the problem here seems to be that the - type required for an array reference of this type is (INTEGER 0 (0)) - which is canonicalized to NIL. - -260: - a. - (let* ((s (gensym)) - (t1 (specifier-type s))) - (eval `(defstruct ,s)) - (type= t1 (specifier-type s))) - => NIL, NIL - - (fixed in 0.8.1.24) - - b. The same for CSUBTYPEP. - -262: "yet another bug in inline expansion of local functions" - 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 - behaviour of streams with element-type (SIGNED-BYTE 8). The patch - looks reasonable, if not obviously correct; however, it caused the - PPC/Linux port to segfault during warm-init while loading - src/pcl/std-class.fasl. A workaround patch was made, but it would - be nice to understand why the first patch caused problems, and to - fix the cause if possible. - -268: "wrong free declaration scope" - The following code must signal type error: - - (locally (declare (optimize (safety 3))) - (flet ((foo (x &optional (y (car x))) - (declare (optimize (safety 0))) - (list x y))) - (funcall (eval #'foo) 1))) - -270: - In the following function constraint propagator optimizes nothing: - - (defun foo (x) - (declare (integer x)) - (declare (optimize speed)) - (typecase x - (fixnum "hala") - (fixnum "buba") - (bignum "hip") - (t "zuz"))) - -273: - Compilation of the following two forms causes "X is unbound" error: - - (symbol-macrolet ((x pi)) - (macrolet ((foo (y) (+ x y))) - (declaim (inline bar)) - (defun bar (z) - (* z (foo 4))))) - (defun quux (z) - (bar z)) - - (See (COERCE (CDR X) 'FUNCTION) in IR1-CONVERT-INLINE-LAMBDA.) - -274: - CLHS says that type declaration of a symbol macro should not affect - its expansion, but in SBCL it does. (If you like magic and want to - fix it, don't forget to change all uses of MACROEXPAND to - MACROEXPAND*.) - -275: - The following code (taken from CLOCC) takes a lot of time to compile: - - (defun foo (n) - (declare (type (integer 0 #.large-constant) n)) - (expt 1/10 n)) - - (fixed in 0.8.2.51, but a test case would be good) - -276: - b. The same as in a., but using MULTIPLE-VALUE-SETQ instead of SETQ. - c. (defvar *faa*) - (defmethod faa ((*faa* double-float)) - (set '*faa* (when (< *faa* 0) (- *faa*))) - (1+ *faa*)) - (faa 1d0) => type error - -279: type propagation error -- correctly inferred type goes astray? - In sbcl-0.8.3 and sbcl-0.8.1.47, the warning - The binding of ABS-FOO is a (VALUES (INTEGER 0 0) - &OPTIONAL), not a (INTEGER 1 536870911) - is emitted when compiling this file: - (declaim (ftype (function ((integer 0 #.most-positive-fixnum)) - (integer #.most-negative-fixnum 0)) - foo)) - (defun foo (x) - (- x)) - (defun bar (x) - (let* (;; Uncomment this for a type mismatch warning indicating - ;; that the type of (FOO X) is correctly understood. - #+nil (fs-foo (float-sign (foo x))) - ;; Uncomment this for a type mismatch warning - ;; indicating that the type of (ABS (FOO X)) is - ;; correctly understood. - #+nil (fs-abs-foo (float-sign (abs (foo x)))) - ;; something wrong with this one though - (abs-foo (abs (foo x)))) - (declare (type (integer 1 100) abs-foo)) - (print abs-foo))) - - (see also bug 117) - -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 - strongly suspected problems, as of 0.8.3.10: please update this - bug instead of creating new ones - - localtime() - called for timezone calculations in code/time.lisp - -284: Thread safety: special variables - There are lots of special variables in SBCL, and I feel sure that at - least some of them are indicative of potentially thread-unsafe - parts of the system. See doc/internals/notes/threading-specials - -286: "recursive known functions" - Self-call recognition conflicts with known function - recognition. Currently cross compiler and target COMPILE do not - recognize recursion, and in target compiler it can be disabled. We - can always disable it for known functions with RECURSIVE attribute, - but there remains a possibility of a function with a - (tail)-recursive simplification pass and transforms/VOPs for base - cases. - -287: PPC/Linux miscompilation or corruption in first GC - When the runtime is compiled with -O3 on certain PPC/Linux machines, a - segmentation fault is reported at the point of first triggered GC, - during the compilation of DEFSTRUCT WRAPPER. As a temporary workaround, - the runtime is no longer compiled with -O3 on PPC/Linux, but it is likely - that this merely obscures, not solves, the underlying problem; as and when - underlying problems are fixed, it would be worth trying again to provoke - this problem. - -288: fundamental cross-compilation issues (from old UGLINESS file) - 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. - (block nil (let () (funcall #'+ (eval 'nil) (eval '1) (return :good)))) - signals type error. - - Our policy is to check argument types at the moment of a call. It - disagrees with ANSI, which says that type assertions are put - immediately onto argument expressions, but is easier to implement in - IR1 and is more compatible to type inference, inline expansion, - etc. IR1-transforms automatically keep this policy, but source - transforms for associative functions (such as +), being applied - during IR1-convertion, do not. It may be tolerable for direct calls - (+ x y z), but for (FUNCALL #'+ x y z) it is non-conformant. - - b. Another aspect of this problem is efficiency. [x y + z +] - requires less registers than [x y z + +]. This transformation is - currently performed with source transforms, but it would be good to - also perform it in IR1 optimization phase. - -290: Alpha floating point and denormalized traps - In SBCL 0.8.3.6x on the alpha, we work around what appears to be a - hardware or kernel deficiency: the status of the enable/disable - denormalized-float traps bit seems to be ambiguous; by the time we - get to os_restore_fp_control after a trap, denormalized traps seem - to be enabled. Since we don't want a trap every time someone uses a - denormalized float, in general, we mask out that bit when we restore - the control word; however, this clobbers any change the user might - have made. - -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. - -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. - -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 - -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? - -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. - -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." - - 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. - -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. - - On x86/linux large portions of tests/debug.impure.lisp have been commented - out as failures. The probable culprit for these problems is in x86-call-context - (things work fine on x86/freebsd). - - 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) - - Since SBCL 0.8.20.1 this is hidden unless *SHOW-ENTRY-POINT-DETAILS* - is true (instead there appear two TEST frames at least on ppc). The - underlying cause seems to be that SB-C::TAIL-ANNOTATE will not merge - the tail-call for the XEP, since Python has by that time proved that - the function can never return; same happens if the function holds an - unconditional call to ERROR. - -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 - -367: TYPE-ERROR at compile time, undetected TYPE-ERROR at runtime - This test program - (declaim (optimize (safety 3) (debug 2) (speed 2) (space 1))) - (defstruct e367) - (defstruct i367) - (defstruct g367 - (i367s (make-array 0 :fill-pointer t) :type (or (vector i367) null))) - (defstruct s367 - (g367 (error "missing :G367") :type g367 :read-only t)) - ;;; In sbcl-0.8.18, commenting out this (DECLAIM (FTYPE ... R367)) - ;;; gives an internal error at compile time: - ;;; The value # is not of - ;;; type SB-KERNEL:VALUES-TYPE. - (declaim (ftype (function ((vector i367) e367) (or s367 null)) r367)) - (declaim (ftype (function ((vector e367)) (values)) h367)) - (defun frob (v w) - (let ((x (g367-i367s (make-g367)))) - (let* ((y (or (r367 x w) - (h367 x))) - (z (s367-g367 y))) - (format t "~&Y=~S Z=~S~%" y z) - (g367-i367s z)))) - (defun r367 (x y) (declare (ignore x y)) nil) - (defun h367 (x) (declare (ignore x)) (values)) - ;;; In sbcl-0.8.18, executing this form causes an low-level error - ;;; segmentation violation at #X9B0E1F4 - ;;; (instead of the TYPE-ERROR that one might like). - (frob 0 (make-e367)) - can be made to cause two different problems, as noted in the comments: - bug 367a: Compile and load the file. No TYPE-ERROR is signalled at - run time (in the (S367-G367 Y) form of FROB, when Y is NIL - instead of an instance of S367). Instead (on x86/Linux at least) - we end up with a segfault. - bug 367b: Comment out the (DECLAIM (FTYPE ... R367)), and compile - the file. The compiler fails with TYPE-ERROR at compile time. - -368: miscompiled OR (perhaps related to bug 367) - Trying to relax type declarations to find a workaround for bug 367, - it turns out that even when the return type isn't declared (or - declared to be T, anyway) the system remains confused about type - inference in code similar to that for bug 367: - (in-package :cl-user) - (declaim (optimize (safety 3) (debug 2) (speed 2) (space 1))) - (defstruct e368) - (defstruct i368) - (defstruct g368 - (i368s (make-array 0 :fill-pointer t) :type (or (vector i368) null))) - (defstruct s368 - (g368 (error "missing :G368") :type g368 :read-only t)) - (declaim (ftype (function (fixnum (vector i368) e368) t) r368)) - (declaim (ftype (function (fixnum (vector e368)) t) h368)) - (defparameter *h368-was-called-p* nil) - (defun nsu (vertices e368) - (let ((i368s (g368-i368s (make-g368)))) - (let ((fuis (r368 0 i368s e368))) - (format t "~&FUIS=~S~%" fuis) - (or fuis (h368 0 i368s))))) - (defun r368 (w x y) - (declare (ignore w x y)) - nil) - (defun h368 (w x) - (declare (ignore w x)) - (setf *h368-was-called-p* t) - (make-s368 :g368 (make-g368))) - (trace r368 h368) - (format t "~&calling NSU~%") - (let ((nsu (nsu #() (make-e368)))) - (format t "~&NSU returned ~S~%" nsu) - (format t "~&*H368-WAS-CALLED-P*=~S~%" *h368-was-called-p*) - (assert (s368-p nsu)) - (assert *h368-was-called-p*)) - In sbcl-0.8.18, both ASSERTs fail, and (DISASSEMBLE 'NSU) shows - that no call to H368 is compiled. - -369: unlike-an-intersection behavior of VALUES-TYPE-INTERSECTION - In sbcl-0.8.18.2, the identity $(x \cap y \cap y)=(x \cap y)$ - does not hold for VALUES-TYPE-INTERSECTION, even for types which - can be intersected exactly, so that ASSERTs fail in this test case: - (in-package :cl-user) - (let ((types (mapcar #'sb-c::values-specifier-type - '((values (vector package) &optional) - (values (vector package) &rest t) - (values (vector hash-table) &rest t) - (values (vector hash-table) &optional) - (values t &optional) - (values t &rest t) - (values nil &optional) - (values nil &rest t) - (values sequence &optional) - (values sequence &rest t) - (values list &optional) - (values list &rest t))))) - (dolist (x types) - (dolist (y types) - (let ((i (sb-c::values-type-intersection x y))) - (assert (sb-c::type= i (sb-c::values-type-intersection i x))) - (assert (sb-c::type= i (sb-c::values-type-intersection i y))))))) - -370: reader misbehaviour on large-exponent floats - (read-from-string "1.0s1000000000000000000000000000000000000000") - causes the reader to attempt to create a very large bignum (which it - will then attempt to coerce to a rational). While this isn't - completely wrong, it is probably not ideal -- checking the floating - point control word state and then returning the relevant float - (most-positive-short-float or short-float-infinity) or signalling an - error immediately would seem to make more sense. - -372: floating-point overflow not signalled on ppc/darwin - The following assertions in float.pure.lisp fail on ppc/darwin - (Mac OS X version 10.3.7): - (assert (raises-error? (scale-float 1.0 most-positive-fixnum) - floating-point-overflow)) - (assert (raises-error? (scale-float 1.0d0 (1+ most-positive-fixnum)) - floating-point-overflow))) - as the SCALE-FLOAT just returns - #.SB-EXT:SINGLE/DOUBLE-FLOAT-POSITIVE-INFINITY. These tests have been - disabled on Darwin for now. - -375: MISC.555 - (compile nil '(lambda (p1) - (declare (optimize (speed 1) (safety 2) (debug 2) (space 0)) - (type keyword p1)) - (keywordp p1))) - - fails on hairy type check in IR2. - - 1. KEYWORDP is MAYBE-INLINE expanded (before TYPEP-like - transformation could eliminate it). - - 2. From the only call of KEYWORDP the type of its argument is - derived to be KEYWORD. - - 2. Type check for P1 is generated; it uses KEYWORDP to perform the - check, and so references the local function; from the KEYWORDP - argument type new CAST to KEYWORD is generated. The compiler - loops forever. - -377: Memory fault error reporting - On those architectures where :C-STACK-IS-CONTROL-STACK is in - *FEATURES*, we handle SIG_MEMORY_FAULT (SEGV or BUS) on an altstack, - so we cannot handle the signal directly (as in interrupt_handle_now()) - in the case when the signal comes from some external agent (the user - using kill(1), or a fault in some foreign code, for instance). As - of sbcl-0.8.20.20, this is fixed by calling - arrange_return_to_lisp_function() to a new error-signalling - function, but as a result the error reporting is poor: we cannot - even tell the user at which address the fault occurred. We should - arrange such that arguments can be passed to the function called from - arrange_return_to_lisp_function(), but this looked hard to do in - general without suffering from memory leaks. - -379: TRACE :ENCAPSULATE NIL broken on ppc/darwin - See commented-out test-case in debug.impure.lisp. - -380: Accessor redefinition fails because of old accessor name - When redefining an accessor, SB-PCL::FIX-SLOT-ACCESSORS may try to - find the generic function named by the old accessor name using - ENSURE-GENERIC-FUNCTION and then remove the old accessor's method in - the GF. If the old name does not name a function, or if the old name - does not name a generic function, no attempt to find the GF or remove - any methods is made. - - However, if an unrelated GF with an incompatible lambda list exists, - the class redefinition will fail when SB-PCL::REMOVE-READER-METHOD - tries to find and remove a method with an incompatible lambda list - from the unrelated generic function. - -381: incautious calls to EQUAL in fasl dumping - Compiling - (frob #(#1=(a #1#))) - (frob #(#1=(b #1#))) - (frob #(#1=(a #1#))) - in sbcl-0.9.0 causes CONTROL-STACK-EXHAUSTED. My (WHN) impression - is that this follows from the use of (MAKE-HASH-TABLE :TEST 'EQUAL) - to detect sharing, in which case fixing it might require either - getting less ambitious about detecting shared list structure, or - implementing the moral equivalent of EQUAL hash tables in a - cycle-tolerant way. - -382: externalization unexpectedly changes array simplicity - COMPILE-FILE and LOAD - (defun foo () - (let ((x #.(make-array 4 :fill-pointer 0))) - (values (eval `(typep ',x 'simple-array)) - (typep x 'simple-array)))) - then (FOO) => T, NIL. - - Similar problems exist with SIMPLE-ARRAY-P, ARRAY-HEADER accessors - and all array dimension functions. - -383: ASH'ing non-constant zeros - Compiling - (lambda (b) - (declare (type (integer -2 14) b)) - (declare (ignorable b)) - (ash (imagpart b) 57)) - on PPC (and other platforms, presumably) gives an error during the - emission of FASH-ASH-LEFT/FIXNUM=>FIXNUM as the assembler attempts to - stuff a too-large constant into the immediate field of a PPC - instruction. Either the VOP should be fixed or the compiler should be - taught how to transform this case away, paying particular attention - to side-effects that might occur in the arguments to ASH. - -384: Compiler runaway on very large character types - - (compile nil '(lambda (x) - (declare (type (member #\a 1) x)) - (the (member 1 nil) x))) - - The types apparently normalize into a very large type, and the compiler - gets lost in REMOVE-DUPLICATES. Perhaps the latter should use - a better algorithm (one based on hash tables, say) on very long lists - when :TEST has its default value? - - A simpler example: - - (compile nil '(lambda (x) (the (not (eql #\a)) x))) - - (partially fixed in 0.9.3.1, but a better representation for these - types is needed.) - -385: - (format nil "~4,1F" 0.001) => "0.00" (should be " 0.0"); - (format nil "~4,1@F" 0.001) => "+.00" (should be "+0.0"). - -386: SunOS/x86 stack exhaustion handling broken - According to , the - stack exhaustion checking (implemented with a write-protected guard - page) does not work on SunOS/x86. - -387: - 12:10 < jsnell> the package-lock test is basically due to a change in the test - behaviour when you install a handler for error around it. I - thought I'd disabled the test for now, but apparently that was - my imagination - 12:19 < Xophe> jsnell: ah, I see the problem in the package-locks stuff - 12:19 < Xophe> it's the same problem as we had with compiler-error conditions - 12:19 < Xophe> the thing that's signalled up and down the stack is a subtype of - ERROR, where it probably shouldn't be - -388: - (found by Dmitry Bogomolov) - - (defclass foo () ((x :type (unsigned-byte 8)))) - (defclass bar () ((x :type symbol))) - (defclass baz (foo bar) ()) - - causes error - - SB-PCL::SPECIALIZER-APPLICABLE-USING-TYPE-P cannot handle the second argument - (UNSIGNED-BYTE 8). - -389: - (reported several times on sbcl-devel, by Rick Taube, Brian Rowe and - others) - - ROUND-NUMERIC-BOUND assumes that float types always have a FORMAT - specifying whether they're SINGLE or DOUBLE. This is true for types - computed by the type system itself, but the compiler type derivation - short-circuits this and constructs non-canonical types. A temporary - fix was made to ROUND-NUMERIC-BOUND for the sbcl-0.9.6 release, but - the right fix is to remove the abstraction violation in the - compiler's type deriver. - -392: slot-accessor for subclass misses obsoleted superclass - (fixed in sbcl-0.9.7.9) - -393: Wrong error from methodless generic function - (DEFGENERIC FOO (X)) - (FOO 1 2) - gives NO-APPLICABLE-METHOD rather than an argument count error. - -394: (SETF CLASS-NAME)/REINITIALIZE-INSTANCE bug - (found by PFD ansi-tests) - in sbcl-0.9.7.15, (SETF (CLASS-NAME ) 'NIL) causes - (FIND-CLASS NIL) to return a #. +Refer to User Manual for more details.