X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=e905d426929b45263151e6486b66a59de5b14416;hb=9a2e730f74641e7de6ad4099111db92c5ad863bf;hp=720e5f65cc6895e9710f9a62b83dc87cc380ad22;hpb=a530bbe337109d898d5b4a001fc8f1afa3b5dc39;p=sbcl.git diff --git a/BUGS b/BUGS index 720e5f6..729c8d2 100644 --- a/BUGS +++ b/BUGS @@ -1,17 +1,18 @@ -REPORTING BUGS +tREPORTING BUGS 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 -Please please please include enough information in a bug report -that someone reading it can reproduce the problem, i.e. don't write +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*?) - Under sbcl-1.2.3, when I compile and load the file + 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))))) @@ -21,106 +22,83 @@ but instead the program loops endlessly instead of printing the object. -KNOWN PORT-SPECIFIC BUGS +NOTES: -The breakpoint-based TRACE facility doesn't work properly in the -OpenBSD port of sbcl-0.6.7. +There is also some information on bugs in the manual page and +in the TODO file. Eventually more such information may move here. -KNOWN BUGS +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). -(There is also some information on bugs in the manual page and in the -TODO file. Eventually more such information may move here.) -* (DESCRIBE NIL) causes an endless loop. +KNOWN BUGS OF NO SPECIAL CLASS: -* The FUNCTION special operator doesn't check properly whether its - argument is a function name. E.g. (FUNCTION (X Y)) returns a value - instead of failing with an error. - -* (DESCRIBE 'GF) fails where GF is the name of a generic function: - The function SB-IMPL::DESCRIBE-INSTANCE is undefined. - -* Failure in initialization files is not handled gracefully -- it's - a throw to TOP-LEVEL-CATCHER, which is not caught until we enter - TOPLEVEL-REPL. Code should be added to catch such THROWs even when - we're not in TOPLEVEL-REPL and do *something* with them (probably - complaining about an error outside TOPLEVEL-REPL, perhaps printing - a BACKTRACE, then terminating execution of SBCL). - -* COMPILED-FUNCTION-P bogusly reports T for interpreted functions: - * (DEFUN FOO (X) (- 12 X)) - FOO - * (COMPILED-FUNCTION-P #'FOO) - T - -* The CL:STEP macro is undefined. - -* DEFSTRUCT should almost certainly overwrite the old LAYOUT information +2: + DEFSTRUCT almost certainly should overwrite the old LAYOUT information instead of just punting when a contradictory structure definition - is loaded. - -* It should cause a STYLE-WARNING, not a full WARNING, when a structure - slot default value does not match the declared structure slot type. - (The current behavior is consistent with SBCL's behavior elsewhere, - and would not be a problem, except that the other behavior is - specifically required by the ANSI spec.) - -* It should cause a STYLE-WARNING, not a WARNING, when the system ignores - an FTYPE proclamation for a slot accessor. - -* Missing ordinary arguments in a macro call aren't reported when the - macro lambda list contains &KEY: - (DEFMACRO FOO (BAR &KEY) BAR) => FOO - (FOO) => NIL - Also in DESTRUCTURING-BIND: - (DESTRUCTURING-BIND (X Y &REST REST) '(1) (VECTOR X Y REST)) - => #(1 NIL NIL) - Also with &REST lists: - (DEFMACRO FOO (BAR &REST REST) BAR) => FOO - (FOO) => NIL - -* Error reporting on various stream-requiring operations is not - very good when the stream argument has the wrong type, because - the operation tries to fall through to Gray stream code, and then - dies because it's undefined. E.g. - (PRINT-UNREADABLE-OBJECT (*STANDARD-OUTPUT* 1)) - gives the error message - error in SB-KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER: - The function SB-IMPL::STREAM-WRITE-STRING is undefined. - It would be more useful and correct to signal a TYPE-ERROR: - not a STREAM: 1 - (It wouldn't be terribly difficult to write stubs for all the - Gray stream functions that the old CMU CL code expects, with - each stub just raising the appropriate TYPE-ERROR.) - -* bogus warnings about undefined functions for magic functions like + 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: + 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. + +6: + bogus warnings about undefined functions for magic functions like SB!C::%%DEFUN and SB!C::%DEFCONSTANT when cross-compiling files - like src/code/float.lisp - -* The "byte compiling top-level form:" output ought to be condensed. + like src/code/float.lisp. Fixing this will probably require + straightening out enough bootstrap consistency issues that + the cross-compiler can run with *TYPE-SYSTEM-INITIALIZED*. + Instead, the cross-compiler runs in a slightly flaky state + which is sane enough to compile SBCL itself, but which is + also unstable in several ways, including its inability + to really grok function declarations. + + As of sbcl-0.7.5, sbcl's cross-compiler does run with + *TYPE-SYSTEM-INITIALIZED*; however, this bug remains. + +7: + The "compiling top-level form:" output ought to be condensed. Perhaps any number of such consecutive lines ought to turn into a - single "byte compiling top-level forms:" line. - -* The handling of IGNORE declarations on lambda list arguments of DEFMETHOD - is at least weird, and in fact seems broken and useless. I should - fix up another layer of binding, declared IGNORABLE, for typed - lambda list arguments. - -* Compiling a file containing the erroneous program - (DEFSTRUCT FOO - A - B) - (DEFSTRUCT (BAR (:INCLUDE FOO)) - A - B) - gives only the not-very-useful message - caught ERROR: - (during macroexpansion) - Condition PROGRAM-ERROR was signalled. - (The specific message which says that the problem was duplicate - slot names gets lost.) + single "compiling top-level forms:" line. -* The way that the compiler munges types with arguments together +10: + The way that the compiler munges types with arguments together with types with no arguments (in e.g. TYPE-EXPAND) leads to weirdness visible to the user: (DEFTYPE FOO () 'FIXNUM) @@ -131,9 +109,13 @@ TODO file. Eventually more such information may move here.) The situation is complicated by the presence of Common Lisp types like UNSIGNED-BYTE (which can either be used in list form or alone) so I'm not 100% sure that the behavior above is actually illegal. - But I'm 90+% sure, and someday perhaps I'll be motivated to look it up.. + But I'm 90+% sure, and the following related behavior, + (TYPEP 11 'AND) => T + treating the bare symbol AND as equivalent to '(AND), is specifically + forbidden (by the ANSI specification of the AND type). -* It would be nice if the +11: + It would be nice if the caught ERROR: (during macroexpansion) said what macroexpansion was at fault, e.g. @@ -141,320 +123,36 @@ TODO file. Eventually more such information may move here.) (during macroexpansion of IN-PACKAGE, during macroexpansion of DEFFOO) -* The type system doesn't understand the KEYWORD type very well: - (SUBTYPEP 'KEYWORD 'SYMBOL) => NIL, NIL - It might be possible to fix this by changing the definition of - KEYWORD to (AND SYMBOL (SATISFIES KEYWORDP)), but the type system - would need to be a bit smarter about AND types, too: - (SUBTYPEP '(AND SYMBOL KEYWORD) 'SYMBOL) => NIL, NIL - (The type system does know something about AND types already, - (SUBTYPEP '(AND INTEGER FLOAT) 'NUMBER) => T, T - (SUBTYPEP '(AND INTEGER FIXNUM) 'NUMBER) =>T, T - so likely this is a small patch.) - -* Floating point infinities are screwed up. [When I was converting CMU CL - to SBCL, I was looking for complexity to delete, and I thought it was safe - to just delete support for floating point infinities. It wasn't: they're - generated by the floating point hardware even when we remove support - for them in software. -- WHN] Support for them should be restored. - -* The ANSI syntax for non-STANDARD method combination types in CLOS is - (DEFGENERIC FOO (X) (:METHOD-COMBINATION PROGN)) - (DEFMETHOD FOO PROGN ((X BAR)) (PRINT 'NUMBER)) - If you mess this up, omitting the PROGN qualifier in in DEFMETHOD, - (DEFGENERIC FOO (X) (:METHOD-COMBINATION PROGN)) - (DEFMETHOD FOO ((X BAR)) (PRINT 'NUMBER)) - the error mesage is not easy to understand: - INVALID-METHOD-ERROR was called outside the dynamic scope - of a method combination function (inside the body of - DEFINE-METHOD-COMBINATION or a method on the generic - function COMPUTE-EFFECTIVE-METHOD). - It would be better if it were more informative, a la - The method combination type for this method (STANDARD) does - not match the method combination type for the generic function - (PROGN). - Also, after you make the mistake of omitting the PROGN qualifier - on a DEFMETHOD, doing a new DEFMETHOD with the correct qualifier - no longer works: - (DEFMETHOD FOO PROGN ((X BAR)) (PRINT 'NUMBER)) - gives - INVALID-METHOD-ERROR was called outside the dynamic scope - of a method combination function (inside the body of - DEFINE-METHOD-COMBINATION or a method on the generic - function COMPUTE-EFFECTIVE-METHOD). - This is not very helpful.. - -* The message "The top of the stack was encountered." from the debugger - is not helpful when I type "FRAME 0" -- I know I'm going to the top - of the stack. - -* (SUBTYPEP '(FUNCTION (T BOOLEAN) NIL) +15: + (SUBTYPEP '(FUNCTION (T BOOLEAN) NIL) '(FUNCTION (FIXNUM FIXNUM) NIL)) => T, T (Also, when this is fixed, we can enable the code in PROCLAIM which checks for incompatible FTYPE redeclarations.) -* The ANSI spec says that CONS can be a compound type spec, e.g. - (CONS FIXNUM REAL). SBCL doesn't support this. - -* from Paolo Amoroso on the CMU CL mailing list 27 Feb 2000: - I use CMU CL 18b under Linux. When COMPILE-FILE is supplied a physical -pathname, the type of the corresponding compiled file is X86F: - * (compile-file "/home/paolo/lisp/tools/foo") - Python version 1.0, VM version Intel x86 on 27 FEB 0 06:00:46 pm. - Compiling: /home/paolo/lisp/tools/foo.lisp 27 FEB 0 05:57:42 pm - Converted SQUARE. - Compiling DEFUN SQUARE: - Byte Compiling Top-Level Form: - /home/paolo/lisp/tools/foo.x86f written. - Compilation finished in 0:00:00. - #p"/home/paolo/lisp/tools/foo.x86f" - NIL - NIL -But when the function is called with a logical pathname, the file type -becomes FASL: - * (compile-file "tools:foo") - Python version 1.0, VM version Intel x86 on 27 FEB 0 06:01:04 pm. - Compiling: /home/paolo/lisp/tools/foo.lisp 27 FEB 0 05:57:42 pm - Converted SQUARE. - Compiling DEFUN SQUARE: - Byte Compiling Top-Level Form: - TOOLS:FOO.FASL written. - Compilation finished in 0:00:00. - #p"/home/paolo/lisp/tools/foo.fasl" - NIL - NIL - -* from DTC on the CMU CL mailing list 25 Feb 2000: -;;; Compiler fails when this file is compiled. -;;; -;;; Problem shows up in delete-block within ir1util.lisp. The assertion -;;; (assert (member (functional-kind lambda) '(:let :mv-let :assignment))) -;;; fails within bind node branch. -;;; -;;; Note that if c::*check-consistency* is enabled then an un-reached -;;; entry is also reported. -;;; -(defun foo (val) - (declare (values nil)) - nil) -(defun bug (val) - (multiple-value-call - #'(lambda (res) - (block nil - (tagbody - loop - (when res - (return nil)) - (go loop)))) - (foo val)) - (catch 'ccc1 - (throw 'ccc1 - (block bbbb - (tagbody - - (let ((ttt #'(lambda () (go cccc)))) - (declare (special ttt)) - (return-from bbbb nil)) - - cccc - (return-from bbbb nil)))))) - -* (I *think* this is a bug. It certainly seems like strange behavior. But - the ANSI spec is scary, dark, and deep..) +19: + (I *think* this is a bug. It certainly seems like strange behavior. But + the ANSI spec is scary, dark, and deep.. -- WHN) (FORMAT NIL "~,1G" 1.4) => "1. " (FORMAT NIL "~3,1G" 1.4) => "1. " -* from Marco Antoniotti on cmucl-imp mailing list 1 Mar 2000: +20: + from Marco Antoniotti on cmucl-imp mailing list 1 Mar 2000: (defclass ccc () ()) (setf (find-class 'ccc1) (find-class 'ccc)) (defmethod zut ((c ccc1)) 123) + In sbcl-0.7.1.13, this gives an error, + There is no class named CCC1. DTC's recommended workaround from the mailing list 3 Mar 2000: (setf (pcl::find-class 'ccc1) (pcl::find-class 'ccc)) -* There's probably a bug in the compiler handling of special variables - in closures, inherited from the CMU CL code, as reported on the - CMU CL mailing list. There's a patch for this on the CMU CL - mailing list too: - Message-ID: <38C8E188.A1E38B5E@jeack.com.au> - Date: Fri, 10 Mar 2000 22:50:32 +1100 - From: "Douglas T. Crosher" - -* The ANSI spec, in section "22.3.5.2 Tilde Less-Than-Sign: Logical Block", - says that an error is signalled if ~W, ~_, ~<...~:>, ~I, or ~:T is used - inside "~<..~>" (without the colon modifier on the closing syntax). - However, SBCL doesn't do this: - * (FORMAT T "~" 12) - munge12egnum - NIL - -* When too many files are opened, OPEN will fail with an - uninformative error message - error in function OPEN: error opening #P"/tmp/foo.lisp": NIL - instead of saying that too many files are open. - -* Right now, when COMPILE-FILE has a read error, it actually pops - you into the debugger before giving up on the file. It should - instead handle the error, perhaps issuing (and handling) - a secondary error "caught ERROR: unrecoverable error during compilation" - and then return with FAILURE-P true, - -* The print system doesn't conform to ANSI - "22.1.3.3.1 Package Prefixes for Symbols" for keywords printed when - *PACKAGE* is the KEYWORD package. - - from a message by Ray Toy on CMU CL mailing list Fri, 28 Apr 2000: - -In a discussion on comp.lang.lisp, the following code was given (by -Erik Naggum): - -(let ((*package* (find-package :keyword))) - (write-to-string object :readably t)) - -If OBJECT is a keyword, CMUCL prints out the keyword, but without a -colon. Hence, it's not readable, as requested. - -I think the following patch will make this work as expected. The -patch just basically checks for the keyword package first before -checking the current package. - -Ray - ---- ../cmucl-18c/src/code/print.lisp Wed Dec 8 14:33:47 1999 -+++ ../cmucl-18c/new/code/print.lisp Fri Apr 28 09:21:29 2000 -@@ -605,12 +605,12 @@ - (let ((package (symbol-package object)) - (name (symbol-name object))) - (cond -- ;; If the symbol's home package is the current one, then a -- ;; prefix is never necessary. -- ((eq package *package*)) - ;; If the symbol is in the keyword package, output a colon. - ((eq package *keyword-package*) - (write-char #\: stream)) -+ ;; If the symbol's home package is the current one, then a -+ ;; prefix is never necessary. -+ ((eq package *package*)) - ;; Uninterned symbols print with a leading #:. - ((null package) - (when (or *print-gensym* *print-readably*) - -* from CMU CL mailing list 01 May 2000 - -I realize I can take care of this by doing (proclaim (ignore pcl::.slots1.)) -but seeing as .slots0. is not-exported, shouldn't it be ignored within the -+expansion -when not used? - -In: DEFMETHOD FOO-BAR-BAZ (RESOURCE-TYPE) - (DEFMETHOD FOO-BAR-BAZ - ((SELF RESOURCE-TYPE)) - (SETF (SLOT-VALUE SELF 'NAME) 3)) ---> BLOCK MACROLET PCL::FAST-LEXICAL-METHOD-FUNCTIONS ---> PCL::BIND-FAST-LEXICAL-METHOD-MACROS MACROLET ---> PCL::BIND-LEXICAL-METHOD-FUNCTIONS LET PCL::BIND-ARGS LET* PCL::PV-BINDING ---> PCL::PV-BINDING1 PCL::PV-ENV LET -==> - (LET ((PCL::.SLOTS0. #)) - (PROGN SELF) - (BLOCK FOO-BAR-BAZ - (LET # - #))) -Warning: Variable PCL::.SLOTS0. defined but never used. - -Compilation unit finished. - 1 warning - -# - -* reported by Sam Steingold on the cmucl-imp mailing list 12 May 2000: - -Also, there is another bug: `array-displacement' should return an array -or nil as first value (as per ANSI CL), while CMUCL declares it as -returning an array as first value always. - -* Sometimes (SB-EXT:QUIT) fails with +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. -* The system accepts DECLAIM in most places where DECLARE would be - accepted, without even issuing a warning. ANSI allows this, but since - it's fairly easy to mistype DECLAIM instead of DECLARE, and the - meaning is rather different, and it's unlikely that the user - has a good reason for doing DECLAIM not at top level, it would be - good to issue a STYLE-WARNING when this happens. A possible - fix would be to issue STYLE-WARNINGs for DECLAIMs not at top level, - or perhaps to issue STYLE-WARNINGs for any EVAL-WHEN not at top level. - -* There seems to be some sort of bug in the interaction of the - normal compiler, the byte compiler, and type predicates. - Compiling and loading this file - (IN-PACKAGE :CL-USER) - (DEFSTRUCT FOO A B) - (PROGN - (DECLAIM (FTYPE (FUNCTION (FOO) FOO) FOO-BAR)) - (DECLAIM (INLINE FOO-BAR)) - (DEFUN FOO-BAR (FOO) - (DECLARE (TYPE FOO FOO)) - (LET ((RESULT2605 (BLOCK FOO-BAR (PROGN (THE FOO (FOO-A FOO)))))) - (UNLESS (TYPEP RESULT2605 'FOO) - (LOCALLY (ERROR "OOPS"))) - (THE FOO RESULT2605))) - 'FOO-BAR) - (DEFPARAMETER *FOO* (MAKE-FOO :A (MAKE-FOO))) - (UNLESS (EQ *PRINT-LEVEL* 133) - (DEFUN CK? () - (LABELS ((FLOOD () - (WHEN (TYPEP *X* 'FOO) - (FOO-BAR *Y*)))))) - (PRINT 11) - (PRINT (FOO-BAR *FOO*)) - (PRINT 12)) - in sbcl-0.6.5 (or also in CMU CL 18b for FreeBSD) gives a call - to the undefined function SB-C::%INSTANCE-TYPEP. %INSTANCE-TYPEP - is not defined as a function because it's supposed to - be transformed away. My guess is what's happening is that - the mixture of toplevel and non-toplevel stuff and inlining - is confusing the system into compiling an %INSTANCE-TYPEP - form into byte code, where the DEFTRANSFORM which is supposed - to get rid of such forms is not effective. - -* some sort of bug in inlining and RETURN-FROM in sbcl-0.6.5: Compiling - (DEFUN BAR? (X) - (OR (NAR? X) - (BLOCK USED-BY-SOME-Y? - (FLET ((FROB (STK) - (DOLIST (Y STK) - (UNLESS (REJECTED? Y) - (RETURN-FROM USED-BY-SOME-Y? T))))) - (DECLARE (INLINE FROB)) - (FROB (RSTK X)) - (FROB (MRSTK X))) - NIL))) - gives - error in function SB-KERNEL:ASSERT-ERROR: - The assertion (EQ (SB-C::CONTINUATION-KIND SB-C::CONT) :BLOCK-START) failed. - -* The CMU CL reader code takes liberties in binding the standard read table - when reading the names of characters. Tim Moore posted a patch to the - CMU CL mailing list Mon, 22 May 2000 21:30:41 -0700. - -* In some cases the compiler believes type declarations on array - elements without checking them, e.g. - (DECLAIM (OPTIMIZE (SAFETY 3) (SPEED 1) (SPACE 1))) - (DEFSTRUCT FOO A B) - (DEFUN BAR (X) - (DECLARE (TYPE (SIMPLE-ARRAY CONS 1) X)) - (WHEN (CONSP (AREF X 0)) - (PRINT (AREF X 0)))) - (BAR (VECTOR (MAKE-FOO :A 11 :B 12))) - prints - #S(FOO :A 11 :B 12) - in SBCL 0.6.5 (and also in CMU CL 18b). This does not happen for - all cases, e.g. the type assumption *is* checked if the array - elements are declared to be of some structure type instead of CONS. - -* The printer doesn't report closures very well. This is true in +32: + The printer doesn't report closures very well. This is true in CMU CL 18b as well: (PRINT #'CLASS-NAME) gives @@ -463,45 +161,18 @@ returning an array as first value always. and make things like DEFSTRUCT and FLET, which create closures, set helpful values into this slot. -* And as long as we're wishing, it would be awfully nice if INSPECT could +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. -* as reported by Robert Strandh on the CMU CL mailing list 12 Jun 2000: - $ cat xx.lisp - (defconstant +a-constant+ (make-instance 'a-class)) - (defconstant +another-constant+ (vector +a-constant+)) - $ lisp - CMU Common Lisp release x86-linux 2.4.19 8 February 2000 build 456, - running on - bobby - Send bug reports and questions to your local CMU CL maintainer, - or to pvaneynd@debian.org - or to cmucl-help@cons.org. (prefered) - type (help) for help, (quit) to exit, and (demo) to see the demos - Loaded subsystems: - Python 1.0, target Intel x86 - CLOS based on PCL version: September 16 92 PCL (f) - * (defclass a-class () ()) - # - * (compile-file "xx.lisp") - Python version 1.0, VM version Intel x86 on 12 JUN 00 08:12:55 am. - Compiling: - /home/strandh/Research/Functional/Common-Lisp/CLIM/Development/McCLIM - /xx.lisp 12 JUN 00 07:47:14 am - Compiling Load Time Value of (PCL::GET-MAKE-INSTANCE-FUNCTION-SYMBOL - '(A-CLASS NIL NIL)): - Byte Compiling Top-Level Form: - Error in function C::DUMP-STRUCTURE: Attempt to dump invalid - structure: - # - How did this happen? - -* The compiler assumes that any time a function of declared FTYPE +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))) - (DECLAIM (FTYPE (FUNCTION (UNSIGNED-BYTE) FACTORIAL))) + (DEFUN GAMMA (X) X) + (DECLAIM (FTYPE (FUNCTION (UNSIGNED-BYTE)) FACTORIAL)) (DEFUN FOO (X) (COND ((> (FACTORIAL X) 1.0E6) (FORMAT T "too big~%")) @@ -524,71 +195,11 @@ returning an array as first value always. 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.) -* As pointed out by Martin Cracauer on the CMU CL mailing list - 13 Jun 2000, the :FILE-LENGTH operation for - FD-STREAM-MISC-ROUTINE is broken for large files: it says - (THE INDEX SIZE) even though SIZE can be larger than INDEX. - -* In SBCL 0.6.5 (and CMU CL 18b) compiling and loading - (in-package :cl-user) - (declaim (optimize (safety 3) - (debug 3) - (compilation-speed 2) - (space 1) - (speed 2) - #+nil (sb-ext:inhibit-warnings 2))) - (declaim (ftype (function * (values)) emptyvalues)) - (defun emptyvalues (&rest rest) (declare (ignore rest)) (values)) - (defstruct foo x y) - (defgeneric assertoid ((x t))) - (defmethod assertoid ((x t)) "just a placeholder") - (defun bar (ht) - (declare (type hash-table ht)) - (let ((res - (block blockname - (progn - (prog1 - (emptyvalues) - (assertoid (hash-table-count ht))))))) - (unless (typep res 'foo) - (locally - (common-lisp-user::bad-result-from-assertive-typed-fun - 'bar - res))))) - then executing - (bar (make-hash-table)) - causes the failure - Error in KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER: - the function C::%INSTANCE-TYPEP is undefined. - %INSTANCE-TYPEP is always supposed to be IR1-transformed away, but for - some reason -- the (VALUES) return value declaration? -- the optimizer is - confused and compiles a full call to %INSTANCE-TYPEP (which doesn't exist - as a function) instead. - -* DEFMETHOD doesn't check the syntax of &REST argument lists properly, - accepting &REST even when it's not followed by an argument name: - (DEFMETHOD FOO ((X T) &REST) NIL) - -* On the CMU CL mailing list 26 June 2000, Douglas Crosher wrote - - Hannu Rummukainen wrote: - ... - > There's something weird going on with the compilation of the attached - > code. Compiling and loading the file in a fresh lisp, then invoking - > (test-it) gives - Thanks for the bug report, nice to have this one fixed. It was a bug - in the x86 backend, the < VOP. A fix has been committed to the main - source, see the file compiler/x86/float.lisp. - - Probably the same bug exists in SBCL. - -* TYPEP treats the result of UPGRADED-ARRAY-ELEMENT-TYPE as gospel, - so that (TYPEP (MAKE-ARRAY 3) '(VECTOR SOMETHING-NOT-DEFINED-YET)) - returns (VALUES T T). Probably it should be an error instead, - complaining that the type SOMETHING-NOT-DEFINED-YET is not defined. - -* TYPEP of VALUES types is sometimes implemented very inefficiently, e.g. in +41: + TYPEP of VALUES types is sometimes implemented very inefficiently, e.g. in (DEFTYPE INDEXOID () '(INTEGER 0 1000)) (DEFUN FOO (X) (DECLARE (TYPE INDEXOID X)) @@ -600,134 +211,89 @@ returning an array as first value always. from the ANSI CL standard) as discussed on the cmucl-imp@cons.org mailing list, e.g. in Robert Maclachlan's post of 21 Jun 2000. -* The definitions of SIGCONTEXT-FLOAT-REGISTER and +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. -* (as discussed by Douglas Crosher on the cmucl-imp mailing list ca. - Aug. 10, 2000): CMUCL currently interprets 'member as '(member); same issue - with 'union, 'and, 'or etc. So even though according to the ANSI spec, - bare 'MEMBER, 'AND, and 'OR are not legal types, CMUCL (and now - SBCL) interpret them as legal types. - -* ANSI specifies DEFINE-SYMBOL-MACRO, but it's not defined in SBCL. - CMU CL added it ca. Aug 13, 2000, after some discussion on the mailing - list, and it is probably possible to use substantially the same - patches to add it to SBCL. +43: + (as discussed by Douglas Crosher on the cmucl-imp mailing list ca. + Aug. 10, 2000): CMUCL currently interprets 'member as '(member); same + issue with 'union, 'and, 'or etc. So even though according to the + ANSI spec, bare 'MEMBER, 'AND, and 'OR are not legal types, CMUCL + (and now SBCL) interpret them as legal types. -* a slew of floating-point-related errors reported by Peter Van Eynde +45: + a slew of floating-point-related errors reported by Peter Van Eynde on July 25, 2000: - * (SQRT -9.0) fails, because SB-KERNEL::COMPLEX-SQRT is undefined. - Similarly, COMPLEX-ASIN, COMPLEX-ACOS, COMPLEX-ACOSH, and others - aren't found. - * SBCL's value for LEAST-POSITIVE-SHORT-FLOAT is bogus, and - should probably be 1.4012985e-45. In SBCL, - (/ LEAST-POSITIVE-SHORT-FLOAT 2) returns a number smaller - than LEAST-POSITIVE-SHORT-FLOAT. Similar problems - exist for LEAST-NEGATIVE-SHORT-FLOAT, LEAST-POSITIVE-LONG-FLOAT, - and LEAST-NEGATIVE-LONG-FLOAT. - * Many expressions generate floating infinity: + b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT is bogus, and + should probably be 1.4012985e-45. In SBCL, + (/ LEAST-POSITIVE-SHORT-FLOAT 2) returns a number smaller + than LEAST-POSITIVE-SHORT-FLOAT. Similar problems + exist for LEAST-NEGATIVE-SHORT-FLOAT, LEAST-POSITIVE-LONG-FLOAT, + and LEAST-NEGATIVE-LONG-FLOAT. + 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 - generates the infinities instead, which may or may not be - conforming behavior, but then blow it by being unable to - output the infinities, since support for infinities is generally - broken, and in particular SB-IMPL::OUTPUT-FLOAT-INFINITY is - undefined. - * (in section12.erg) various forms a la - (FLOAT 1 DOUBLE-FLOAT-EPSILON) don't give the right behavior. - -* type safety errors reported by Peter Van Eynde July 25, 2000: - * (COERCE (QUOTE (A B C)) (QUOTE (VECTOR * 4))) - => #(A B C) - In general lengths of array type specifications aren't - checked by COERCE, so it fails when the spec is - (VECTOR 4), (STRING 2), (SIMPLE-BIT-VECTOR 3), or whatever. - * CONCATENATE has the same problem of not checking the length - of specified output array types. MAKE-SEQUENCE and MAP and - MERGE also have the same problem. - * (COERCE 'AND 'FUNCTION) returns something related to - (MACRO-FUNCTION 'AND), but ANSI says it should raise an error. - * ELT signals SIMPLE-ERROR if its index argument - isn't a valid index for its sequence argument, but should - signal TYPE-ERROR instead. - * FILE-LENGTH is supposed to signal a type error when its - argument is not a stream associated with a file, but doesn't. - * (FLOAT-RADIX 2/3) should signal an error instead of - returning 2. - * (LOAD "*.lsp") should signal FILE-ERROR. - * (MAKE-CONCATENATED-STREAM (MAKE-STRING-OUTPUT-STREAM)) - should signal TYPE-ERROR. - * MAKE-TWO-WAY-STREAM doesn't check that its arguments can - be used for input and output as needed. It should fail with - TYPE-ERROR when handed e.g. the results of MAKE-STRING-INPUT-STREAM - or MAKE-STRING-OUTPUT-STREAM in the inappropriate positions, - but doesn't. - * (PARSE-NAMESTRING (COERCE (LIST #\f #\o #\o (CODE-CHAR 0) #\4 #\8) - (QUOTE STRING))) - should probably signal an error instead of making a pathname with - a null byte in it. - * READ-BYTE is supposed to signal TYPE-ERROR when its argument is - not a binary input stream, but instead cheerfully reads from - character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc"). - -* DEFCLASS bugs reported by Peter Van Eynde July 25, 2000: - * (DEFCLASS FOO () (A B A)) should signal a PROGRAM-ERROR, and doesn't. - * (DEFCLASS FOO () (A B A) (:DEFAULT-INITARGS X A X B)) should - signal a PROGRAM-ERROR, and doesn't. - * (DEFCLASS FOO07 NIL ((A :ALLOCATION :CLASS :ALLOCATION :CLASS))), - and other DEFCLASS forms with duplicate specifications in their - slots, should signal a PROGRAM-ERROR, and doesn't. - * (DEFGENERIC IF (X)) should signal a PROGRAM-ERROR, but instead - causes a COMPILER-ERROR. - -* SYMBOL-MACROLET bugs reported by Peter Van Eynde July 25, 2000: - * (SYMBOL-MACROLET ((T TRUE)) ..) should probably signal - PROGRAM-ERROR, but SBCL accepts it instead. - * SYMBOL-MACROLET should refuse to bind something which is - declared as a global variable, signalling PROGRAM-ERROR. - * SYMBOL-MACROLET should signal PROGRAM-ERROR if something - it binds is declared SPECIAL inside. - -* LOOP bugs reported by Peter Van Eynde July 25, 2000: - * (LOOP WITH (A B) DO (PRINT 1)) is a syntax error according to - the definition of WITH clauses given in the ANSI spec, but - compiles and runs happily in SBCL. - * a messy one involving package iteration: -interpreted Form: (LET ((PACKAGE (MAKE-PACKAGE "LOOP-TEST"))) (INTERN "blah" PACKAGE) (LET ((BLAH2 (INTERN "blah2" PACKAGE))) (EXPORT BLAH2 PACKAGE)) (LIST (SORT (LOOP FOR SYM BEING EACH PRESENT-SYMBOL OF PACKAGE FOR SYM-NAME = (SYMBOL-NAME SYM) COLLECT SYM-NAME) (FUNCTION STRING<)) (SORT (LOOP FOR SYM BEING EACH EXTERNAL-SYMBOL OF PACKAGE FOR SYM-NAME = (SYMBOL-NAME SYM) COLLECT SYM-NAME) (FUNCTION STRING<)))) -Should be: (("blah" "blah2") ("blah2")) -SBCL: (("blah") ("blah2")) - * (LET ((X 1)) (LOOP FOR I BY (INCF X) FROM X TO 10 COLLECT I)) - doesn't work -- SBCL's LOOP says BY isn't allowed in a FOR clause. - -* type system errors reported by Peter Van Eynde July 25, 2000: - * (SUBTYPEP 'BIGNUM 'INTEGER) => NIL, NIL - but should be (VALUES T T) instead. - * (SUBTYPEP 'EXTENDED-CHAR 'CHARACTER) => NIL, NIL - but should be (VALUES T T) instead. - * (SUBTYPEP '(INTEGER (0) (0)) 'NIL) dies with nested errors. - * In general, the system doesn't like '(INTEGER (0) (0)) -- it - blows up at the level of SPECIFIER-TYPE with - "Lower bound (0) is greater than upper bound (0)." Probably - SPECIFIER-TYPE should return NIL instead. - * (TYPEP 0 '(COMPLEX (EQL 0)) fails with - "Component type for Complex is not numeric: (EQL 0)." - This might be easy to fix; the type system already knows - that (SUBTYPEP '(EQL 0) 'NUMBER) is true. - * The type system doesn't know about the condition system, - so that e.g. (TYPEP 'SIMPLE-ERROR 'ERROR)=>NIL. - * The type system isn't all that smart about relationships - between hairy types, as shown in the type.erg test results, - e.g. (SUBTYPEP 'CONS '(NOT ATOM)) => NIL, NIL. - -* miscellaneous errors reported by Peter Van Eynde July 25, 2000: - * (PROGN + 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: + a: (COERCE (QUOTE (A B C)) (QUOTE (VECTOR * 4))) + => #(A B C) + In general lengths of array type specifications aren't + checked by COERCE, so it fails when the spec is + (VECTOR 4), (STRING 2), (SIMPLE-BIT-VECTOR 3), or whatever. + b: CONCATENATE has the same problem of not checking the length + of specified output array types. MAKE-SEQUENCE and MAP and + MERGE also have the same problem. + c: (COERCE 'AND 'FUNCTION) returns something related to + (MACRO-FUNCTION 'AND), but ANSI says it should raise an error. + h: (MAKE-CONCATENATED-STREAM (MAKE-STRING-OUTPUT-STREAM)) + should signal TYPE-ERROR. + i: MAKE-TWO-WAY-STREAM doesn't check that its arguments can + be used for input and output as needed. It should fail with + TYPE-ERROR when handed e.g. the results of + MAKE-STRING-INPUT-STREAM or MAKE-STRING-OUTPUT-STREAM in + the inappropriate positions, but doesn't. + k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is + not a binary input stream, but instead cheerfully reads from + character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc"). + +47: + DEFCLASS bugs reported by Peter Van Eynde July 25, 2000: + a: (DEFCLASS FOO () (A B A)) should signal a PROGRAM-ERROR, and + doesn't. + b: (DEFCLASS FOO () (A B A) (:DEFAULT-INITARGS X A X B)) should + signal a PROGRAM-ERROR, and doesn't. + c: (DEFCLASS FOO07 NIL ((A :ALLOCATION :CLASS :ALLOCATION :CLASS))), + and other DEFCLASS forms with duplicate specifications in their + slots, should signal a PROGRAM-ERROR, and doesn't. + d: (DEFGENERIC IF (X)) should signal a PROGRAM-ERROR, but instead + causes a COMPILER-ERROR. + +48: + SYMBOL-MACROLET bugs reported by Peter Van Eynde July 25, 2000: + c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something + it binds is declared SPECIAL inside. + +51: + miscellaneous errors reported by Peter Van Eynde July 25, 2000: + a: (PROGN (DEFGENERIC FOO02 (X)) (DEFMETHOD FOO02 ((X NUMBER)) T) (LET ((M (FIND-METHOD (FUNCTION FOO02) @@ -737,43 +303,1093 @@ SBCL: (("blah") ("blah2")) (DEFGENERIC FOO03 (X)) (ADD-METHOD (FUNCTION FOO03) M))) should give an error, but SBCL allows it. - * READ should probably return READER-ERROR, not the bare - arithmetic error, when input a la "1/0" or "1e1000" causes - an arithmetic error. - * There are several metaobject protocol "errors". (In order to fix - them, we might need to document exactly what metaobject - protocol specification we're following -- the current code is - just inherited from PCL.) - * (BUTLAST NIL) should return NIL. (This appears to be a compiler - bug, since the definition of BUTLAST, when interpreted, does - give (BUTLAST NIL)=>NIL.) - -* another error from Peter Van Eynde 5 September 2000: - (FORMAT NIL "~F" "FOO") should work, but instead reports an error. - PVE submitted a patch to deal with this bug, but it exposes other - comparably serious bugs, so I didn't apply it. It looks as though - the FORMAT code needs a fair amount of rewriting in order to comply - with the various details of the ANSI spec. - -* The bug discussed on the cmucl-imp@cons.org mailing list ca. 5 September, - simplified by Douglas Crosher down to - (defun tickle-bug () - (labels ((fun1 () - (fun2)) - (fun2 () - (when nil - (tagbody - tag - (fun2) - (go tag))) - (when nil - (tagbody - tag - (fun1) - (go tag))))) - (fun1) - nil)) - causes the same problem on SBCL: compiling it fails with - :LET fell through ECASE expression. - Very likely the patch discussed there is appropriate for SBCL - as well, but I don't understand it, so I didn't apply it. + b: READ should probably return READER-ERROR, not the bare + arithmetic error, when input a la "1/0" or "1e1000" causes + an arithmetic error. + +52: + It has been reported (e.g. by Peter Van Eynde) that there are + several metaobject protocol "errors". (In order to fix them, we might + need to document exactly what metaobject protocol specification + we're following -- the current code is just inherited from PCL.) + +54: + The implementation of #'+ returns its single argument without + type checking, e.g. (+ "illegal") => "illegal". + +60: + The debugger LIST-LOCATIONS command doesn't work properly. + +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. + +62: + The compiler is supposed to do type inference well enough that + the declaration in + (TYPECASE X + ((SIMPLE-ARRAY SINGLE-FLOAT) + (LOCALLY + (DECLARE (TYPE (SIMPLE-ARRAY SINGLE-FLOAT) X)) + ..)) + ..) + is redundant. However, as reported by Juan Jose Garcia Ripoll for + CMU CL, it sometimes doesn't. Adding declarations is a pretty good + workaround for the problem for now, but can't be done by the TYPECASE + macros themselves, since it's too hard for the macro to detect + assignments to the variable within the clause. + Note: The compiler *is* smart enough to do the type inference in + many cases. This case, derived from a couple of MACROEXPAND-1 + calls on Ripoll's original test case, + (DEFUN NEGMAT (A) + (DECLARE (OPTIMIZE SPEED (SAFETY 0))) + (COND ((TYPEP A '(SIMPLE-ARRAY SINGLE-FLOAT)) NIL + (LET ((LENGTH (ARRAY-TOTAL-SIZE A))) + (LET ((I 0) (G2554 LENGTH)) + (DECLARE (TYPE REAL G2554) (TYPE REAL I)) + (TAGBODY + SB-LOOP::NEXT-LOOP + (WHEN (>= I G2554) (GO SB-LOOP::END-LOOP)) + (SETF (ROW-MAJOR-AREF A I) (- (ROW-MAJOR-AREF A I))) + (GO SB-LOOP::NEXT-LOOP) + SB-LOOP::END-LOOP)))))) + demonstrates the problem; but the problem goes away if the TAGBODY + and GO forms are removed (leaving the SETF in ordinary, non-looping + code), or if the TAGBODY and GO forms are retained, but the + assigned value becomes 0.0 instead of (- (ROW-MAJOR-AREF A I)). + +63: + Paul Werkowski wrote on cmucl-imp@cons.org 2000-11-15 + I am looking into this problem that showed up on the cmucl-help + list. It seems to me that the "implementation specific environment + hacking functions" found in pcl/walker.lisp are completely messed + up. The good thing is that they appear to be barely used within + PCL and the munged environment object is passed to cmucl only + in calls to macroexpand-1, which is probably why this case fails. + SBCL uses essentially the same code, so if the environment hacking + is screwed up, it affects us too. + +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. + +66: + ANSI specifies that the RESULT-TYPE argument of CONCATENATE must be + a subtype of SEQUENCE, but CONCATENATE doesn't check this properly: + (CONCATENATE 'SIMPLE-ARRAY #(1 2) '(3)) => #(1 2 3) + This also leads to funny behavior when derived type specifiers + are used, as originally reported by Milan Zamazal for CMU CL (on the + Debian bugs mailing list (?) 2000-02-27), then reported by Martin + Atzmueller for SBCL (2000-10-01 on sbcl-devel@lists.sourceforge.net): + (DEFTYPE FOO () 'SIMPLE-ARRAY) + (CONCATENATE 'FOO #(1 2) '(3)) + => # is a bad type specifier for + sequence functions. + The derived type specifier FOO should act the same way as the + built-in type SIMPLE-ARRAY here, but it doesn't. That problem + doesn't seem to exist for sequence types: + (DEFTYPE BAR () 'SIMPLE-VECTOR) + (CONCATENATE 'BAR #(1 2) '(3)) => #(1 2 3) + See also bug #46a./b., and discussion and patch sbcl-devel and + cmucl-imp 2002-07 + +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. + +72: + (DECLAIM (OPTIMIZE ..)) doesn't work properly inside LOCALLY forms. + +75: + As reported by Martin Atzmueller on sbcl-devel 26 Dec 2000, + ANSI says that WITH-OUTPUT-TO-STRING should have a keyword + :ELEMENT-TYPE, but in sbcl-0.6.9 this is not defined for + WITH-OUTPUT-TO-STRING. + +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.) + +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. + +82: + Functions are assigned names based on the context in which they're + defined. This is less than ideal for the functions which are + used to implement CLOS methods. E.g. the output of + (DESCRIBE 'PRINT-OBJECT) lists functions like + # + and + # + It would be better if these functions' names always identified + them as methods, and identified their generic functions and + specializers. + +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.) + +94a: + Inconsistencies between derived and declared VALUES return types for + DEFUN aren't checked very well. E.g. the logic which successfully + catches problems like + (declaim (ftype (function (fixnum) float) foo)) + (defun foo (x) + (declare (type integer x)) + (values x)) ; wrong return type, detected, gives warning, good! + fails to catch + (declaim (ftype (function (t) (values t t)) bar)) + (defun bar (x) + (values x)) ; wrong number of return values, no warning, bad! + The cause of this is seems to be that (1) the internal function + VALUES-TYPES-EQUAL-OR-INTERSECT used to make the check handles its + arguments symmetrically, and (2) when the type checking code was + written back when when SBCL's code was still CMU CL, the intent + was that this case + (declaim (ftype (function (t) t) bar)) + (defun bar (x) + (values x x)) ; wrong number of return values; should give warning? + not be warned for, because a two-valued return value is considered + to be compatible with callers who expects a single value to be + returned. That intent is probably not appropriate for modern ANSI + Common Lisp, but fixing this might be complicated because of other + divergences between auld-style and new-style handling of + multiple-VALUES types. (Some issues related to this were discussed + on cmucl-imp at some length sometime in 2000.) + +95: + The facility for dumping a running Lisp image to disk gets confused + when run without the PURIFY option, and creates an unnecessarily large + core file (apparently representing memory usage up to the previous + high-water mark). Moreover, when the file is loaded, it confuses the + GC, so that thereafter memory usage can never be reduced below that + level. + +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. + A proper solution involves deciding whether it's really worth + saving space by implementing structure slot accessors as closures. + (If it's not worth it, the problem vanishes automatically. If it + is worth it, there are hacks we could use to force type tests to + be compiled anyway, and even shared. E.g. we could implement + an EQUAL hash table mapping from types to compiled type tests, + and save the appropriate compiled type test as part of each lexical + closure; or we could make the lexical closures be placeholders + which overwrite their old definition as a lexical closure with + a new compiled definition the first time that they're called.) + 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-impl::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. + +104: + (DESCRIBE 'SB-ALIEN:DEF-ALIEN-TYPE) reports the macro argument list + incorrectly: + DEF-ALIEN-TYPE is + an external symbol + in #. + Macro-function: # + Macro arguments: (#:whole-470 #:environment-471) + On Sat, May 26, 2001 09:45:57 AM CDT it was compiled from: + /usr/stuff/sbcl/src/code/host-alieneval.lisp + Created: Monday, March 12, 2001 07:47:43 AM CST + +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). + +110: + reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs + collection: + ;;; The compiler is flushing the argument type test, and the default + ;;; case in the cond, so that calling with say a fixnum 0 causes a + ;;; SIGBUS. + (declaim (optimize (safety 2) (speed 3))) + (defun tst (x) + (declare (type (or string stream) x)) + (cond ((typep x 'string) 'string) + ((typep x 'stream) 'stream) + (t + 'none))) + The symptom in sbcl-0.6.12.42 on OpenBSD is actually (TST 0)=>STREAM + (not the SIGBUS reported in the comment) but that's broken too; + type declarations are supposed to be treated as assertions unless + SAFETY 0, so we should be getting a TYPE-ERROR. + +113: + reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs + collection: + (in-package :cl-user) + ;;; From: David Gadbois + ;;; + ;;; Logical pathnames aren't externalizable. + ;;; Test case: + (let ((tempfile "/tmp/test.lisp")) + (setf (logical-pathname-translations "XXX") + '(("XXX:**;*.*" "/tmp/**/*.*"))) + (with-open-file (out tempfile :direction :output) + (write-string "(defvar *path* #P\"XXX:XXX;FOO.LISP\")" out)) + (compile-file tempfile)) + The error message in sbcl-0.6.12.42 is + ; caught ERROR: + ; (while making load form for #) + ; A logical host can't be dumped as a constant: # + +115: + reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs + collection: + (in-package :cl-user) + ;;; The following invokes a compiler error. + (declaim (optimize (speed 2) (debug 3))) + (defun tst () + (flet ((m1 () + (unwind-protect nil))) + (if (catch nil) + (m1) + (m1)))) + The error message in sbcl-0.6.12.42 is + internal error, failed AVER: + "(COMMON-LISP:EQ (SB!C::TN-ENVIRONMENT SB!C:TN) SB!C::TN-ENV)" + +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.. + +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. + +122: + There was some sort of screwup in handling of + (IF (NOT (IGNORE-ERRORS ..))). E.g. + (defun foo1i () + (if (not (ignore-errors + (make-pathname :host "foo" :directory "!bla" :name "bar"))) + (print "ok") + (error "notunlessnot"))) + The (NOT (IGNORE-ERRORS ..)) form evaluates to T, so this should be + printing "ok", but instead it's going to the ERROR. This problem + seems to've been introduced by MNA's HANDLER-CASE patch (sbcl-devel + 2001-07-17) and as a workaround (put in sbcl-0.pre7.14.flaky4.12) + I reverted back to the old weird HANDLER-CASE code. However, I + think the problem looks like a compiler bug in handling RETURN-FROM, + so I left the MNA-patched code in HANDLER-CASE (suppressed with + #+NIL) and I'd like to go back to see whether this really is + a compiler bug before I delete this BUGS entry. + +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. + +125: + (as reported by Gabe Garza on cmucl-help 2001-09-21) + (defvar *tmp* 3) + (defun test-pred (x y) + (eq x y)) + (defun test-case () + (let* ((x *tmp*) + (func (lambda () x))) + (print (eq func func)) + (print (test-pred func func)) + (delete func (list func)))) + Now calling (TEST-CASE) gives output + NIL + NIL + (#) + Evidently Python thinks of the lambda as a code transformation so + much that it forgets that it's also an object. + +127: + The DEFSTRUCT section of the ANSI spec, in the :CONC-NAME section, + specifies a precedence rule for name collisions between slot accessors of + structure classes related by inheritance. As of 0.7.0, SBCL still + doesn't follow it. + +129: + insufficient syntax checking in MACROLET: + (defun foo (x) + (macrolet ((defmacro bar (z) `(+ z z))) + (bar x))) + shouldn't compile without error (because of the extra DEFMACRO symbol). + +131: + As of sbcl-0.pre7.86.flaky7.3, the cross-compiler, and probably + the CL:COMPILE function (which is based on the same %COMPILE + mechanism) get confused by +(defun sxhash (x) + (labels ((sxhash-number (x) + (etypecase x + (fixnum (sxhash x)) ; through DEFTRANSFORM + (integer (sb!bignum:sxhash-bignum x)) + (single-float (sxhash x)) ; through DEFTRANSFORM + (double-float (sxhash x)) ; through DEFTRANSFORM + #!+long-float (long-float (error "stub: no LONG-FLOAT")) + (ratio (let ((result 127810327)) + (declare (type fixnum result)) + (mixf result (sxhash-number (numerator x))) + (mixf result (sxhash-number (denominator x))) + result)) + (complex (let ((result 535698211)) + (declare (type fixnum result)) + (mixf result (sxhash-number (realpart x))) + (mixf result (sxhash-number (imagpart x))) + result)))) + (sxhash-recurse (x &optional (depthoid +max-hash-depthoid+)) + (declare (type index depthoid)) + (typecase x + (list + (if (plusp depthoid) + (mix (sxhash-recurse (car x) (1- depthoid)) + (sxhash-recurse (cdr x) (1- depthoid))) + 261835505)) + (instance + (if (typep x 'structure-object) + (logxor 422371266 + (sxhash ; through DEFTRANSFORM + (class-name (layout-class (%instance-layout x))))) + 309518995)) + (symbol (sxhash x)) ; through DEFTRANSFORM + (number (sxhash-number x)) + (array + (typecase x + (simple-string (sxhash x)) ; through DEFTRANSFORM + (string (%sxhash-substring x)) + (bit-vector (let ((result 410823708)) + (declare (type fixnum result)) + (dotimes (i (min depthoid (length x))) + (mixf result (aref x i))) + result)) + (t (logxor 191020317 (sxhash (array-rank x)))))) + (character + (logxor 72185131 + (sxhash (char-code x)))) ; through DEFTRANSFORM + (t 42)))) + (sxhash-recurse x))) + complaining "function called with two arguments, but wants exactly + one" about SXHASH-RECURSE. (This might not be strictly a new bug, + since IIRC post-fork CMU CL has also had problems with &OPTIONAL + arguments in FLET/LABELS: it might be an old Python bug which is + only exercised by the new arrangement of the SBCL compiler.) + +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. + +136: + (reported by Arnaud Rouanet on cmucl-imp 2001-12-18) + (defmethod foo ((x integer)) + x) + (defmethod foo :around ((x integer)) + (let ((x (1+ x))) + (call-next-method))) + Now (FOO 3) should return 3, but instead it returns 4. + +140: + (reported by Alexey Dejneka sbcl-devel 2002-01-03) + + SUBTYPEP does not work well with redefined classes: + --- + * (defclass a () ()) + # + * (defclass b () ()) + # + * (subtypep 'b 'a) + NIL + T + * (defclass b (a) ()) + # + * (subtypep 'b 'a) + T + T + * (defclass b () ()) + # + + ;;; And now... + * (subtypep 'b 'a) + T + T + + This bug was fixed in sbcl-0.7.4.1 by invalidating the PCL wrapper + class upon redefinition. Unfortunately, doing so causes bug #176 to + appear. Pending further investication, one or other of these bugs + might be present at any given time. + +141: + Pretty-printing nested backquotes doesn't work right, as + reported by Alexey Dejneka sbcl-devel 2002-01-13: + * '``(FOO ,@',@S) + ``(FOO SB-IMPL::BACKQ-COMMA-AT S) + * (lisp-implementation-version) + "0.pre7.129" + +142: + (as reported by Lynn Quam on cmucl-imp ca. 2002-01-16) + %NATURALIZE-C-STRING conses a lot, like 16 bytes per byte + of the naturalized string. We could probably port the patches + from the cmucl-imp mailing list. + +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. + +144: + (This was once known as IR1-4, but it lived on even after the + IR1 interpreter went to the big bit bucket in the sky.) + The system accepts DECLAIM in most places where DECLARE would be + accepted, without even issuing a warning. ANSI allows this, but since + it's fairly easy to mistype DECLAIM instead of DECLARE, and the + meaning is rather different, and it's unlikely that the user + has a good reason for doing DECLAIM not at top level, it would be + good to issue a STYLE-WARNING when this happens. A possible + fix would be to issue STYLE-WARNINGs for DECLAIMs not at top level, + or perhaps to issue STYLE-WARNINGs for any EVAL-WHEN not at top level. + [This is considered an IR1-interpreter-related bug because until + EVAL-WHEN is rewritten, which won't happen until after the IR1 + interpreter is gone, the system's notion of what's a top-level form + and what's not will remain too confused to fix this problem.] + +145: + 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.) + +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 + +148: + In sbcl-0.7.1.3 on x86, COMPILE-FILE on the file + (in-package :cl-user) + (defvar *thing*) + (defvar *zoom*) + (defstruct foo bar bletch) + (defun %zeep () + (labels ((kidify1 (kid) + ) + (kid-frob (kid) + (if *thing* + (setf sweptm + (m+ (frobnicate kid) + sweptm)) + (kidify1 kid)))) + (declare (inline kid-frob)) + (map nil + #'kid-frob + (the simple-vector (foo-bar perd))))) + fails with + debugger invoked on condition of type TYPE-ERROR: + The value NIL is not of type SB-C::NODE. + The location of this failure has moved around as various related + issues were cleaned up. As of sbcl-0.7.1.9, it occurs in + NODE-BLOCK called by LAMBDA-COMPONENT called by IR2-CONVERT-CLOSURE. + +153: + (essentially the same problem as a CMU CL bug reported by Martin + Cracauer on cmucl-imp 2002-02-19) + There is a hole in structure slot type checking. Compiling and LOADing + (declaim (optimize safety)) + (defstruct foo + (bla 0 :type fixnum)) + (defun f () + (let ((foo (make-foo))) + (setf (foo-bla foo) '(1 . 1)) + (format t "Is ~a of type ~a a cons? => ~a~%" + (foo-bla foo) + (type-of (foo-bla foo)) + (consp (foo-bla foo))))) + (f) + should signal an error, but in sbcl-0.7.1.21 instead gives the output + Is (1 . 1) of type CONS a cons? => NIL + without signalling an error. + +157: + Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and + UPGRADED-COMPLEX-PART-TYPE should have an optional environment argument. + (reported by Alexey Dejneka sbcl-devel 2002-04-12) + +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.) + +166: + Compiling + (in-package :cl-user) + (defstruct uustk) + (defmethod permanentize ((uustk uustk)) + (flet ((frob (hash-table test-for-deletion) + ) + (obj-entry.stale? (oe) + (destructuring-bind (key . datum) oe + (declare (type simple-vector key)) + (deny0 (void? datum)) + (some #'stale? key)))) + (declare (inline frob obj-entry.stale?)) + (frob (uustk.args-hash->obj-alist uustk) + #'obj-entry.stale?) + (frob (uustk.hash->memoized-objs-list uustk) + #'objs.stale?)) + (call-next-method)) + in sbcl-0.7.3.11 causes an assertion failure, + failed AVER: + "(NOT +(AND (NULL (BLOCK-SUCC B)) + (NOT (BLOCK-DELETE-P B)) + (NOT (EQ B (COMPONENT-HEAD #)))))" + +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. + +168: + (reported by Dan Barlow on sbcl-devel 2002-05-10) + In sbcl-0.7.3.12, doing + (defstruct foo bar baz) + (compile nil (lambda (x) (or x (foo-baz x)))) + gives an error + debugger invoked on condition of type SB-INT:BUG: + full call to SB-KERNEL:%INSTANCE-REF + This is probably a bug in SBCL itself. [...] + Since this is a reasonable user error, it shouldn't be reported as + an SBCL bug. + +171: + (reported by Pierre Mai while investigating bug 47): + (DEFCLASS FOO () ((A :SILLY T))) + signals a SIMPLE-ERROR, not a PROGRAM-ERROR. + +172: + sbcl's treatment of at least macro lambda lists is too permissive; + e.g., in sbcl-0.7.3.7: + (defmacro foo (&rest rest bar) `(,bar ,rest)) + (macroexpand '(foo quux zot)) -> (QUUX (QUUX ZOT)) + whereas section 3.4.4 of the CLHS doesn't allow required parameters + to come after the rest argument. + +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. + +174: + The error message from attempting to use a #\Return format + directive: + (format nil "~^M") ; replace "^M" with a literal #\Return + debugger invoked on condition of type SB-FORMAT::FORMAT-ERROR: + error in format: unknown format directive + ~ + ^ + is not terribly helpful; this is more noticeable than parallel cases + with e.g. #\Backspace because of the differing newline conventions + on various operating systems. (reported by Harald Hanche-Olsen on + cmucl-help 2002-05-31) + +176: + reported by Alexey Dejneka 08 Jun 2002 in sbcl-devel: + Playing with McCLIM, I've received an error "Unbound variable WRAPPER + in SB-PCL::CHECK-WRAPPER-VALIDITY". + (defun check-wrapper-validity (instance) + (let* ((owrapper (wrapper-of instance))) + (if (not (invalid-wrapper-p owrapper)) + owrapper + (let* ((state (wrapper-state wrapper)) ; !!! + ... + I've tried to replace it with OWRAPPER, but now OBSOLETE-INSTANCE-TRAP + breaks with "NIL is not of type SB-KERNEL:LAYOUT". + SBCL 0.7.4.13. + partial fix: The undefined variable WRAPPER resulted from an error + in recent refactoring, as can be seen by comparing to the code in e.g. + sbcl-0.7.2. Replacing WRAPPER with OWRAPPER (done by WHN in sbcl-0.7.4.22) + should bring the code back to its behavior as of sbcl-0.7.2, but + that still leaves the OBSOLETE-INSTANCE-TRAP bug. An example of + input which triggers that bug is + (dotimes (i 20) + (let ((lastname (intern (format nil "C~D" (1- i)))) + (name (intern (format nil "C~D" i)))) + (eval `(defclass ,name + (,@(if (= i 0) nil (list lastname))) + ())) + (eval `(defmethod initialize-instance :after ((x ,name) &rest any) + (declare (ignore any)))))) + (defclass b () ()) + (defclass c0 (b) ()) + (make-instance 'c19) + + See also bug #140. + +178: "AVER failure compiling confused THEs in FUNCALL" + In sbcl-0.7.4.24, compiling + (defun bug178 (x) + (funcall (the function (the standard-object x)))) + gives + failed AVER: + "(AND (EQ (IR2-CONTINUATION-PRIMITIVE-TYPE 2CONT) FUNCTION-PTYPE) (EQ CHECK T))" + This variant compiles OK, though: + (defun bug178alternative (x) + (funcall (the nil x))) + +181: "bad type specifier drops compiler into debugger" + Compiling + (in-package :cl-user) + (defun bar (x) + (declare (type 0 x)) + (cons x x)) + signals + bad thing to be a type specifier: 0 + which seems fine, but also enters the debugger (instead of having + the compiler handle the error, convert it into a COMPILER-ERROR, and + continue compiling) which seems wrong. + +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) + +185: "top-level forms at the REPL" + * (locally (defstruct foo (a 0 :type fixnum))) + gives an error: + ; caught ERROR: + ; (in macroexpansion of (SB-KERNEL::%DELAYED-GET-COMPILER-LAYOUT BAR)) + however, compiling and loading the same expression in a file works + as expected. + +187: "type inference confusion around DEFTRANSFORM time" + (reported even more verbosely on sbcl-devel 2002-06-28 as "strange + bug in DEFTRANSFORM") + After the file below is compiled and loaded in sbcl-0.7.5, executing + (TCX (MAKE-ARRAY 4 :FILL-POINTER 2) 0) + at the REPL returns an adjustable vector, which is wrong. Presumably + somehow the DERIVE-TYPE information for the output values of %WAD is + being mispropagated as a type constraint on the input values of %WAD, + and so causing the type test to be optimized away. It's unclear how + hand-expanding the DEFTRANSFORM would change this, but it suggests + the DEFTRANSFORM machinery (or at least the way DEFTRANSFORMs are + invoked at a particular phase) is involved. + (cl:in-package :sb-c) + (eval-when (:compile-toplevel) + ;;; standin for %DATA-VECTOR-AND-INDEX + (defknown %dvai (array index) + (values t t) + (foldable flushable)) + (deftransform %dvai ((array index) + (vector t) + * + :important t) + (let* ((atype (continuation-type array)) + (eltype (array-type-specialized-element-type atype))) + (when (eq eltype *wild-type*) + (give-up-ir1-transform + "specialized array element type not known at compile-time")) + (when (not (array-type-complexp atype)) + (give-up-ir1-transform "SIMPLE array!")) + `(if (array-header-p array) + (%wad array index nil) + (values array index)))) + ;;; standin for %WITH-ARRAY-DATA + (defknown %wad (array index (or index null)) + (values (simple-array * (*)) index index index) + (foldable flushable)) + ;;; (Commenting out this optimizer causes the bug to go away.) + (defoptimizer (%wad derive-type) ((array start end)) + (let ((atype (continuation-type array))) + (when (array-type-p atype) + (values-specifier-type + `(values (simple-array ,(type-specifier + (array-type-specialized-element-type atype)) + (*)) + index index index))))) + ) ; EVAL-WHEN + (defun %wad (array start end) + (format t "~&in %WAD~%") + (%with-array-data array start end)) + (cl:in-package :cl-user) + (defun tcx (v i) + (declare (type (vector t) v)) + (declare (notinline sb-kernel::%with-array-data)) + ;; (Hand-expending DEFTRANSFORM %DVAI here also causes the bug to + ;; go away.) + (sb-c::%dvai v i)) + +188: "compiler performance fiasco involving type inference and UNION-TYPE" + (In sbcl-0.7.6.10, DEFTRANSFORM CONCATENATE was commented out until this + bug could be fixed properly, so you won't see the bug unless you restore + the DEFTRANSFORM by hand.) In sbcl-0.7.5.11 on a 700 MHz Pentium III, + (time (compile + nil + '(lambda () + (declare (optimize (safety 3))) + (declare (optimize (compilation-speed 2))) + (declare (optimize (speed 1) (debug 1) (space 1))) + (let ((fn "if-this-file-exists-the-universe-is-strange")) + (load fn :if-does-not-exist nil) + (load (concatenate 'string fn ".lisp") :if-does-not-exist nil) + (load (concatenate 'string fn ".fasl") :if-does-not-exist nil) + (load (concatenate 'string fn ".misc-garbage") + :if-does-not-exist nil))))) + reports + 134.552 seconds of real time + 133.35156 seconds of user run time + 0.03125 seconds of system run time + [Run times include 2.787 seconds GC run time.] + 0 page faults and + 246883368 bytes consed. + BACKTRACE from Ctrl-C in the compilation shows that the compiler is + thinking about type relationships involving types like + #)[:EXTERNAL] + +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 + 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. the examples in CLHS 7.6.5.1 (regarding generic function lambda + lists and &KEY arguments) do not signal errors when they should. + +192: "Python treats free type declarations as promises." + a. original report by Alexey Dejneka (on sbcl-devel 2002-08-26): + (declaim (optimize (speed 0) (safety 3))) + (defun f (x) + (declare (real x)) + (+ x + (locally (declare (single-float x)) + (sin x)))) + Now (F NIL) correctly gives a type error, but (F 100) gives + a segmentation violation. + b. same fundamental problem in a different way, easy to stumble + across if you mistype and declare the wrong index in + (DOTIMES (I ...) (DOTIMES (J ...) (DECLARE ...) ...)): + (declaim (optimize (speed 1) (safety 3))) + (defun trust-assertion (i) + (dotimes (j i) + (declare (type (mod 4) i)) ; when commented out, behavior changes! + (unless (< i 5) + (print j)))) + (trust-assertion 6) ; prints nothing unless DECLARE is commented out + +193: "unhelpful CLOS error reporting when the primary method is missing" + In sbcl-0.7.7, when + (defmethod foo :before ((x t)) (print x)) + is the only method defined on FOO, the error reporting when e.g. + (foo 12) + is relatively unhelpful: + There is no primary method for the generic function + #. + with the offending argument nowhere visible in the backtrace. This + continues even if there *are* primary methods, just not for the + specified arg type, e.g. + (defmethod foo ((x character)) (print x)) + (defmethod foo ((x string)) (print x)) + (defmethod foo ((x pathname)) ...) + In that case it could be very helpful to know what argument value is + falling through the cracks of the defined primary methods, but the + error message stays the same (even BACKTRACE doesn't tell you what the + bad argument value is). + +194: "no error from (THE REAL '(1 2 3)) in some cases" + In sbcl-0.7.7.9, + (multiple-value-prog1 (progn (the real '(1 2 3)))) + returns (1 2 3) instead of signalling an error. Also in sbcl-0.7.7.9, + a more complicated instance of this bug kept + (IGNORE-ERRORS (MIN '(1 2 3))) from returning NIL as it should when + the MIN source transform expanded to (THE REAL '(1 2 3)), because + (IGNORE-ERRORS (THE REAL '(1 2 3))) returns (1 2 3). + Alexey Dejneka pointed out that + (IGNORE-ERRORS (IDENTITY (THE REAL '(1 2 3)))) works as it should. + (IGNORE-ERRORS (VALUES (THE REAL '(1 2 3)))) also works as it should. + Perhaps this is another case of VALUES type intersections behaving + in non-useful ways? + When I (WHN) tried to use the VALUES trick to work around this bug + in the MIN source transform, it didn't work for + (assert (null (ignore-errors (min 1 #(1 2 3))))) + Hand-expanding the source transform, I get + (assert (null (ignore-errors + (let ((arg1 1) + (arg2 (identity (the real #(1 2 3))))) + (if (< arg1 arg2) arg1 arg2))))) + which fails (i.e. the assertion fails, because the IGNORE-ERRORS + doesn't report MIN signalling a type error). At the REPL + (null (ignore-errors + (let ((arg1 1) + (arg2 (identity (the real #(1 2 3))))) + (if (< arg1 arg2) arg1 arg2)))) + => T + but when this expression is used as the body of (DEFUN FOO () ...) + then (FOO)=>NIL. + +195: "confusing reporting of not-a-REAL TYPE-ERRORs from THE REAL" + In sbcl-0.7.7.10, (THE REAL #(1 2 3)) signals a type error which + prints as "This is not a (OR SINGLE-FLOAT DOUBLE-FLOAT RATIONAL)". + The (OR SINGLE-FLOAT DOUBLE-FLOAT RATIONAL) representation of + REAL is unnecessarily confusing, especially since it relies on + internal implementation knowledge that even with SHORT-FLOAT + and LONG-FLOAT left out of the union, this type is equal to REAL. + So it'd be better just to say "This is not a REAL". + +DEFUNCT CATEGORIES OF BUGS + IR1-#: + These labels were used for bugs related to the old IR1 interpreter. + The # values reached 6 before the category was closed down.