X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=fb6a1433e1b49ff4978db02d97fc6175b9989355;hb=8dc064d2296902f01afd9107e89a81146e3771fe;hp=1f4e07b871d89e1c4b2a94b0faaef9a6319294b6;hpb=b33fd6859bbe71667bf9d8a6dbcaf62464bfbee5;p=sbcl.git diff --git a/BUGS b/BUGS index 1f4e07b..fb6a143 100644 --- a/BUGS +++ b/BUGS @@ -183,21 +183,6 @@ 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. - -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. - (Actually, I think the old CMU CL version in SBCL never returns NIL, - i.e. it's not just a declaration problem, but the definition doesn't - behave ANSIly.) - 27: Sometimes (SB-EXT:QUIT) fails with Argh! maximum interrupt nesting depth (4096) exceeded, exiting @@ -281,6 +266,8 @@ WORKAROUND: 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.) 38: DEFMETHOD doesn't check the syntax of &REST argument lists properly, @@ -466,11 +453,6 @@ SBCL: (("blah") ("blah2")) 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)) @@ -492,23 +474,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). - When this is fixed, probably the more-or-less-parallel Unix-level - hacks - DEFAULT-DIRECTORY - %SET-DEFAULT-DIRECTORY - etc.? - should go away. Also we need to figure out what's the proper way to - deal with the interaction of users assigning new values to - *DEFAULT-PATHNAME-DEFAULTS* and cores being saved and restored. - (Perhaps just make restoring from a save always overwrite the old - value with the new Unix-level default directory?) - 60: The debugger LIST-LOCATIONS command doesn't work properly. @@ -573,7 +538,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") @@ -670,7 +635,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)) @@ -973,14 +938,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: This is funny since sbcl-0.6.12.34 knows (SUBTYPEP '(EQL 0) 'NUMBER) => T -107: - (reported as a CMU CL bug by Erik Naggum on comp.lang.lisp - 2001-06-11:) - * (write #*101 :radix t :base 36) - #*#36r1#36r0#36r1 - #*101 - * - 108: (TIME (ROOM T)) reports more than 200 Mbytes consed even for a clean, just-started SBCL system. And it seems to be right: @@ -988,6 +945,159 @@ Error in function C::GET-LAMBDA-TO-COMPILE: 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: # + +114: + reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs + collection: + (in-package :cl-user) + ;;; This file causes the byte compiler to fail. + (declaim (optimize (speed 0) (safety 1))) + (defun tst1 () + (values + (multiple-value-list + (catch 'a + (return-from tst1))))) + The error message in sbcl-0.6.12.42 is + internal error, failed AVER: + "(COMMON-LISP:EQUAL (SB!C::BYTE-BLOCK-INFO-START-STACK SB!INT:INFO) SB!C::STACK)" + +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.. + KNOWN BUGS RELATED TO THE IR1 INTERPRETER (Note: At some point, the pure interpreter (actually a semi-pure @@ -1060,3 +1170,15 @@ 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-5: + (not really a bug, just a wishlist thing which might be easy + when EVAL-WHEN is rewritten..) It might be good for the cross-compiler + to warn about nested EVAL-WHENs. (In ordinary compilation, they're + quite likely to be OK, but in cross-compiled code EVAL-WHENs + are a great source of confusion, so a style warning about anything + unusual could be helpful.) + +IR1-6: + (another wishlist thing..) Reimplement DEFMACRO to be basically + like DEFMACRO-MUNDANELY, just using EVAL-WHEN.