X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=94a87e1743b67aafc5c69ef352df963c919f476b;hb=947522ee16a30d43466c8f86efacee7003e5d85f;hp=a839434ada46a6e89cad1c5d715ef0b27396cdc7;hpb=dfa55a883f94470267b626dae77ce7e7dfac3df6;p=sbcl.git diff --git a/BUGS b/BUGS index a839434..94a87e1 100644 --- a/BUGS +++ b/BUGS @@ -118,33 +118,6 @@ 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 @@ -210,28 +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. - -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. - (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 @@ -315,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, @@ -500,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)) @@ -526,13 +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). - 60: The debugger LIST-LOCATIONS command doesn't work properly. @@ -597,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") @@ -694,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)) @@ -947,6 +888,311 @@ Error in function C::GET-LAMBDA-TO-COMPILE: the first time around, until regression tests are written I'm not comfortable merging the patches in the CVS version of SBCL. +101: + The error message for calls to structure accessors with the + wrong number of arguments is confusing and of the wrong + condition class (TYPE-ERROR instead of PROGRAM-ERROR): + * (defstruct foo x y) + * (foo-x) + debugger invoked on condition of type SIMPLE-TYPE-ERROR: + Structure for accessor FOO-X is not a FOO: + 301988783 + +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.) + +103: + As reported by Arthur Lemmens sbcl-devel 2001-05-05, ANSI's + definition of (LOOP .. DO ..) requires that the terms following + DO all be compound forms. SBCL's implementation of LOOP allows + non-compound forms (like the bare symbol COUNT, in his example) + here. + +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) + Executing + (TYPEP 0 '(COMPLEX (EQL 0))) + signals an error in sbcl-0.6.12.34, + The component type for COMPLEX is not numeric: (EQL 0) + This is funny since sbcl-0.6.12.34 knows + (SUBTYPEP '(EQL 0) 'NUMBER) => T + +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: # + +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.. + +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. + +119: + a bug in the byte compiler and/or interpreter: Compile + (IN-PACKAGE :CL-USER) + (DECLAIM (OPTIMIZE (SPEED 0) (SAFETY 1) (DEBUG 1))) + (DEFUN BAR (&REST DIMS) + (IF (EVERY #'INTEGERP DIMS) + 1 + 2)) + then execute (BAR '(1 2 3 4)). In sbcl-0.pre7.14.flaky4.8 + this gives a TYPE-ERROR, + The value #:UNINITIALIZED-EVAL-STACK-ELEMENT is not + of type (MOD 536870911). + The same error will probably occur in earlier versions as well, + although the name of the uninitialized-element placeholder will + be shorter. + + The same thing happens if the compiler macro expansion of + EVERY into MAP is hand-expanded: + (defun bar2 (dims) + (if (block blockname + (map nil + (lambda (dim) + (let ((pred-value (funcall #'integerp dim))) + (unless pred-value + (return-from blockname + nil)))) + dims) + t) + 1 + 2)) + CMU CL doesn't have this compiler macro expansion, so it was + immune to the original bug in BAR, but once we hand-expand it + into BAR2, CMU CL 18c has the same bug. (Run (BAR '(NIL NIL)).) + + The native compiler handles it fine, both in SBCL and in CMU CL. + +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. + +121: + In sbcl-0.7.14.flaky4.10, the last MAPTEST test case at the end + of tests/map-tests.impure.lisp dies with + The value + #> + :ARGS (#)> + is not of type + SB-C::COMBINATION. + in + (SB-C::GENERATE-BYTE-CODE-FOR-REF + # + # + :WHERE-FROM :DECLARED + :KIND :GLOBAL-FUNCTION>> + #) KNOWN BUGS RELATED TO THE IR1 INTERPRETER @@ -1020,3 +1266,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.