X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=e5fb392e567ac28f11594e0066feaba130405466;hb=74a48d09e08aead6f67204878bdf9be4f448e1e8;hp=a2c61e520f7575b0e59d74bbdf9bd69be6f706a1;hpb=334af30b26555f0bf706f7157b399bdbd4fad548;p=sbcl.git diff --git a/BUGS b/BUGS index a2c61e5..e5fb392 100644 --- a/BUGS +++ b/BUGS @@ -50,31 +50,33 @@ WORKAROUND: 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. ANSI justifies this specification by saying + 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. - 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, e.g. - ERROR). Thus, as a portable workaround, you can use a call to - some known-never-to-return function as the default. E.g. + 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 () NIL) MISSING-ARG) + (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 will compile without complaint and work correctly either - on SBCL or on a completely compliant Common Lisp system. + 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 @@ -88,9 +90,9 @@ WORKAROUND: to really grok function declarations. 7: - The "byte compiling top-level form:" output ought to be condensed. + 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. + single "compiling top-level forms:" line. 10: The way that the compiler munges types with arguments together @@ -118,78 +120,15 @@ WORKAROUND: (during macroexpansion of IN-PACKAGE, during macroexpansion of DEFFOO) -14: - 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.. - 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.) -18: - 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)))))) - 19: (I *think* this is a bug. It certainly seems like strange behavior. But - the ANSI spec is scary, dark, and deep..) + the ANSI spec is scary, dark, and deep.. -- WHN) (FORMAT NIL "~,1G" 1.4) => "1. " (FORMAT NIL "~3,1G" 1.4) => "1. " @@ -210,50 +149,12 @@ WORKAROUND: munge12egnum NIL -23: - 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. - -24: - 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, - -26: - 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. - 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. -29: - 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. - This is still present in sbcl-0.6.8. - 31: In some cases the compiler believes type declarations on array elements without checking them, e.g. @@ -290,7 +191,8 @@ returning an array as first value always. 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~%")) @@ -313,11 +215,8 @@ 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.) - -38: - 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) + (Also, verify that the compiler handles declared function + return types as assertions.) 41: TYPEP of VALUES types is sometimes implemented very inefficiently, e.g. in @@ -387,11 +286,6 @@ returning an array as first value always. 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. - d: ELT signals SIMPLE-ERROR if its index argument - isn't a valid index for its sequence argument, but should - signal TYPE-ERROR instead. - e: FILE-LENGTH is supposed to signal a type error when its - argument is not a stream associated with a file, but doesn't. f: (FLOAT-RADIX 2/3) should signal an error instead of returning 2. g: (LOAD "*.lsp") should signal FILE-ERROR. @@ -431,24 +325,8 @@ returning an array as first value always. c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something it binds is declared SPECIAL inside. -49: - LOOP bugs reported by Peter Van Eynde July 25, 2000: - a: (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. - b: 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. - 50: type system errors reported by Peter Van Eynde July 25, 2000: - a: (SUBTYPEP 'BIGNUM 'INTEGER) => NIL, NIL - but should be (VALUES T T) instead. - b: (SUBTYPEP 'EXTENDED-CHAR 'CHARACTER) => NIL, NIL - but should be (VALUES T T) instead. c: (SUBTYPEP '(INTEGER (0) (0)) 'NIL) dies with nested errors. d: In general, the system doesn't like '(INTEGER (0) (0)) -- it blows up at the level of SPECIFIER-TYPE with @@ -458,8 +336,6 @@ SBCL: (("blah") ("blah2")) "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. - f: The type system doesn't know about the condition system, - so that e.g. (TYPEP 'SIMPLE-ERROR 'ERROR)=>NIL. g: 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. @@ -486,23 +362,10 @@ SBCL: (("blah") ("blah2")) need to document exactly what metaobject protocol specification we're following -- the current code is just inherited from PCL.) -53: - 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. - 54: The implementation of #'+ returns its single argument without type checking, e.g. (+ "illegal") => "illegal". -55: - In sbcl-0.6.7, there is no doc string for CL:PUSH, probably - because it's defined with the DEFMACRO-MUNDANELY macro and something - is wrong with doc string setting in that macro. - 56: Attempting to use COMPILE on something defined by DEFMACRO fails: (DEFMACRO FOO (X) (CONS X X)) @@ -524,13 +387,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: CLOS methods, and then expressing the solutions to stuff like this should become much more straightforward. -- WHN 2001-03-14 -59: - CL:*DEFAULT-PATHNAME-DEFAULTS* doesn't behave as ANSI suggests (reflecting - current working directory). And there's no supported way to update - or query the current working directory (a la Unix "chdir" and "pwd"), - which is functionality that ILISP needs (and currently gets with low-level - hacks). - 60: The debugger LIST-LOCATIONS command doesn't work properly. @@ -595,7 +451,7 @@ Error in function C::GET-LAMBDA-TO-COMPILE: rightward of the correct location. 65: - (probably related to bug #70) + (probably related to bug #70; maybe related to bug #109) As reported by Carl Witty on submit@bugs.debian.org 1999-05-08, compiling this file (in-package "CL-USER") @@ -692,7 +548,7 @@ Error in function C::GET-LAMBDA-TO-COMPILE: or at least issue a warning. 70: - (probably related to bug #65) + (probably related to bug #65; maybe related to bug #109) The compiler doesn't like &OPTIONAL arguments in LABELS and FLET forms. E.g. (DEFUN FIND-BEFORE (ITEM SEQUENCE &KEY (TEST #'EQL)) @@ -721,21 +577,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: 72: (DECLAIM (OPTIMIZE ..)) doesn't work properly inside LOCALLY forms. -74: - As noted in the ANSI specification for COERCE, (COERCE 3 'COMPLEX) - gives a result which isn't COMPLEX. The result type optimizer - for COERCE doesn't know this, perhaps because it was written before - ANSI threw this curveball: the optimizer thinks that COERCE always - returns a result of the specified type. Thus while the interpreted - function - (DEFUN TRICKY (X) (TYPEP (COERCE X 'COMPLEX) 'COMPLEX)) - returns the correct result, - (TRICKY 3) => NIL - the compiled function - (COMPILE 'TRICKY) - does not: - (TRICKY 3) => T - 75: As reported by Martin Atzmueller on sbcl-devel 26 Dec 2000, ANSI says that WITH-OUTPUT-TO-STRING should have a keyword @@ -762,20 +603,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: LOAD-FOREIGN, and (2) hunt for any other code which uses temporary files and make it share the same new safe logic. -80: - (fixed early Feb 2001 by MNA) - -81: - As reported by wbuss@TELDA.NET (Wolfhard Buss) on cmucl-help - 2001-02-14, - According to CLHS - (loop with (a . b) of-type float = '(0.0 . 1.0) - and (c . d) of-type float = '(2.0 . 3.0) - return (list a b c d)) - should evaluate to (0.0 1.0 2.0 3.0). cmucl-18c disagrees and - invokes the debugger: "B is not of type list". - SBCL does the same thing. - 82: Functions are assigned names based on the context in which they're defined. This is less than ideal for the functions which are @@ -811,13 +638,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: (I haven't tried to investigate this bug enough to guess whether there might be any user-level symptoms.) -87: - Despite what the manual says, (DECLAIM (SPEED 0)) doesn't cause - things to be byte compiled. This seems to be true in cmucl-2.4.19, - too: (COMPILE-FILE .. :BYTE-COMPILE T) causes byte-compilation, - but ordinary COMPILE-FILE of a file containing (DECLAIM (SPEED 0)) - does not. - 90: a latent cross-compilation/bootstrapping bug: The cross-compilation host's CL:CHAR-CODE-LIMIT is used in target code in readtable.lisp @@ -838,13 +658,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: clear what's the best fix. (See the "bug in type handling" discussion on cmucl-imp ca. 2001-03-22 and ca. 2001-02-12.) -92: - (< SB-EXT:SINGLE-FLOAT-POSITIVE-INFINITY 100) signals an error: - error in function SB-KERNEL:INTEGER-DECODE-SINGLE-FLOAT: - can't decode NaN or infinity: #.EXT:SINGLE-FLOAT-POSITIVE-INFINITY - This is a bug in the original CMU CL code. I reported it to cmucl-imp - 2001-03-22 in hopes that they'll fix it for us. - 93: In sbcl-0.6.11.26, (COMPILE 'IN-HOST-COMPILATION-MODE) in src/cold/shared.lisp doesn't correctly translate the @@ -864,64 +677,582 @@ Error in function C::GET-LAMBDA-TO-COMPILE: (:LINUX :X86 :IEEE-FLOATING-POINT :SB-CONSTRAIN-FLOAT-TYPE :SB-TEST :SB-INTERPRETER :SB-DOC :UNIX ...) is not of type SYMBOL. +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. + +96: + The TRACE facility can't be used on some kinds of functions. + (Basically, the breakpoint facility was incompletely implemented + in the X86 port of CMU CL, and hasn't been fixed in SBCL.) + +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)))) + +99: + DESCRIBE interacts poorly with *PRINT-CIRCLE*, e.g. the output from + (let ((*print-circle* t)) (describe (make-hash-table))) + is weird, + # is an . (EQL) + Its SIZE is 16. + Its REHASH-SIZE is 1.5. Its REHASH-THRESHOLD is . (1.0) + It holds 0 key/value pairs. + where the ". (EQL)" and ". (1.0)" substrings are screwups. + (This is likely a pretty-printer problem which happens to + be exercised by DESCRIBE, not actually a DESCRIBE problem.) + +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. + +102: + As reported by Arthur Lemmens sbcl-devel 2001-05-05, ANSI + requires that SYMBOL-MACROLET refuse to rebind special variables, + but SBCL doesn't do this. (Also as reported by AL in the same + message, SBCL depended on this nonconforming behavior to build + itself, because of the way that **CURRENT-SEGMENT** was implemented. + As of sbcl-0.6.12.x, this dependence on the nonconforming behavior + has been fixed, but the nonconforming behavior remains.) + +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 + +105: + (DESCRIBE 'STREAM-READ-BYTE) + +106: + (reported by Eric Marsden on cmucl-imp 2001-06-15) + (and APD pointed out on sbcl-devel 2001-12-29 that it's the same + as bug 50e) + +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). + +109: + reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs + collection: + ;;; This file fails to compile. + ;;; Maybe this bug is related to bugs #65, #70 in the BUGS file. + (in-package :cl-user) + (defun tst2 () + (labels + ((eff (&key trouble) + (eff) + ;; nil + ;; Uncomment and it works + )) + (eff))) + In SBCL 0.6.12.42, the problem is + internal error, failed AVER: + "(COMMON-LISP:EQ (SB!C::LAMBDA-TAIL-SET SB!C::CALLER) + (SB!C::LAMBDA-TAIL-SET (SB!C::LAMBDA-HOME SB!C::CALLEE)))" + +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. + +111: + reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs + collection: + (in-package :cl-user) + ;;; Produces an assertion failures when compiled. + (defun foo (z) + (declare (type (or (function (t) t) null) z)) + (let ((z (or z #'identity))) + (declare (type (function (t) t) z)) + (funcall z 1))) + The error in sbcl-0.6.12.42 is + internal error, failed AVER: + "(COMMON-LISP:NOT (COMMON-LISP:EQ SB!C::CHECK COMMON-LISP:T))" + +112: + reported by Martin Atzmueller 2001-06-25; taken from CMU CL bugs + collection; apparently originally reported by Bruno Haible + (in-package :cl-user) + ;;; From: Bruno Haible + ;;; Subject: scope of SPECIAL declarations + ;;; It seems CMUCL has a bug relating to the scope of SPECIAL + ;;; declarations. I observe this with "CMU Common Lisp 18a x86-linux + ;;; 1.4.0 cvs". + (let ((x 0)) + (declare (special x)) + (let ((x 1)) + (let ((y x)) + (declare (special x)) y))) + ;;; Gives: 0 (this should return 1 according to CLHS) + (let ((x 0)) + (declare (special x)) + (let ((x 1)) + (let ((y x) (x 5)) + (declare (special x)) y))) + ;;; Gives: 1 (correct). + The reported results match what we get from the interpreter + in sbcl-0.6.12.42. + +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. + +120a: + The compiler incorrectly figures the return type of + (DEFUN FOO (FRAME UP-FRAME) + (IF (OR (NOT FRAME) + T) + FRAME + "BAR")) + as NIL. + + This problem exists in CMU CL 18c too. When I reported it on + cmucl-imp@cons.org, Raymond Toy replied 23 Aug 2001 with + a partial explanation, but no fix has been found yet. + +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. + +123: + The *USE-IMPLEMENTATION-TYPES* hack causes bugs, particularly + (IN-PACKAGE :SB-KERNEL) + (TYPE= (SPECIFIER-TYPE '(VECTOR T)) + (SPECIFIER-TYPE '(VECTOR UNDEFTYPE))) + Then because of this, the compiler bogusly optimizes + (TYPEP #(11) '(SIMPLE-ARRAY UNDEF-TYPE 1)) + to T. Unfortunately, just setting *USE-IMPLEMENTATION-TYPES* to + NIL around sbcl-0.pre7.14.flaky4.12 didn't work: the compiler complained + about type mismatches (probably harmlessly, another instance of bug 117); + and then cold init died with a segmentation fault. + +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. + +126: + (fixed in 0.pre7.41) + +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). + +130: + reported by Alexey Dejneka on sbcl-devel 2001-11-03 + (defun x (x) + "Return X if X is a non-negative integer." + (let ((step (lambda (%funcall) + (lambda (n) + (cond ((= n 0) 0) + (t (1+ (funcall %funcall (1- n))))))))) + (funcall + ((lambda (a) + (funcall step (lambda (n) + (funcall (funcall a a) n)))) + (lambda (a) + (funcall step (lambda (n) + (funcall (funcall a a) n))))) + x))) + This function returns its argument. But after removing percents it + does not work: "Result of (1- n) is not a function". + +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.) + +132: + Trying to compile + (DEFUN FOO () (CATCH 0 (PRINT 1331))) + gives an error + # is not valid as the second argument to VOP: + SB-C:MAKE-CATCH-BLOCK, + since the TN's primitive type SB-VM::POSITIVE-FIXNUM doesn't allow + any of the SCs allowed by the operand restriction: + (SB-VM::DESCRIPTOR-REG) + The (CATCH 0 ...) construct is bad style (because of unportability + of EQ testing of numbers) but it is legal, and shouldn't cause an + internal compiler error. (This error occurs in sbcl-0.6.13 and in + 0.pre7.86.flaky7.14.) + +133: + Trying to compile something like + (sb!alien:def-alien-routine "breakpoint_remove" sb!c-call:void + (code-obj sb!c-call:unsigned-long) + (pc-offset sb!c-call:int) + (old-inst sb!c-call:unsigned-long)) + in SBCL-0.pre7.86.flaky7.22 after warm init fails with an error + cannot use values types here + probably because the SB-C-CALL:VOID type gets translated to (VALUES). + It should be valid to use VOID for a function return type, so perhaps + instead of calling SPECIFIER-TYPE (which excludes all VALUES types + automatically) we should call VALUES-SPECIFIER-TYPE and handle VALUES + types manually, allowing the special case (VALUES) but still excluding + all more-complex VALUES types. + +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. + +137: + (SB-DEBUG:BACKTRACE) output should start with something + including the name BACKTRACE, not (as in 0.pre7.88) + just "0: (\"hairy arg processor\" ...)". Until about + sbcl-0.pre7.109, the names in BACKTRACE were all screwed + up compared to the nice useful names in sbcl-0.6.13. + Around sbcl-0.pre7.109, they were mostly fixed by using + NAMED-LAMBDA to implement DEFUN. However, there are still + some screwups left, e.g. as of sbcl-0.pre7.109, there are + still some functions named "hairy arg processor" and + "SB-INT:&MORE processor". + +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 + + KNOWN BUGS RELATED TO THE IR1 INTERPRETER -(Note: At some point, the pure interpreter (actually a semi-pure -interpreter aka "the IR1 interpreter") will probably go away, replaced -by constructs like - (DEFUN EVAL (X) (FUNCALL (COMPILE NIL (LAMBDA ..))))) -and at that time these bugs should either go away automatically or -become more tractable to fix. Until then, they'll probably remain, -since some of them aren't considered urgent, and the rest are too hard -to fix as long as so many special cases remain. After the IR1 -interpreter goes away is also the preferred time to start -systematically exterminating cases where debugging functionality -(backtrace, breakpoint, etc.) breaks down, since getting rid of the -IR1 interpreter will reduce the number of special cases we need to -support.) - -IR1-1: - 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. (Later attempting to funcall the - value does cause an error.) - -IR1-2: - COMPILED-FUNCTION-P bogusly reports T for interpreted functions: - * (DEFUN FOO (X) (- 12 X)) - FOO - * (COMPILED-FUNCTION-P #'FOO) - T - -IR1-3: - Executing - (DEFVAR *SUPPRESS-P* T) - (EVAL '(UNLESS *SUPPRESS-P* - (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) - (FORMAT T "surprise!")))) - prints "surprise!". Probably the entire EVAL-WHEN mechanism ought to be - rewritten from scratch to conform to the ANSI definition, abandoning - the *ALREADY-EVALED-THIS* hack which is used in sbcl-0.6.8.9 (and - in the original CMU CL source, too). This should be easier to do -- - though still nontrivial -- once the various IR1 interpreter special - cases are gone. - -IR1-3a: - EVAL-WHEN's idea of what's a toplevel form is even more screwed up - than the example in IR1-3 would suggest, since COMPILE-FILE and - COMPILE both print both "right now!" messages when compiling the - following code, - (LAMBDA (X) - (COND (X - (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) - (PRINT "yes! right now!")) - "yes!") - (T - (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) - (PRINT "no! right now!")) - "no!"))) - and while EVAL doesn't print the "right now!" messages, the first - FUNCALL on the value returned by EVAL causes both of them to be printed. +(Now that the IR1 interpreter has gone away, these should be +relatively straightforward to fix.) IR1-4: The system accepts DECLAIM in most places where DECLARE would be @@ -936,3 +1267,7 @@ IR1-4: 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.] + +IR1-6: + (another wishlist thing..) Reimplement DEFMACRO to be basically + like DEFMACRO-MUNDANELY, just using EVAL-WHEN.