X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=2c29d33917ab91bbffd8727c4fc806d4820efd03;hb=9514c25e89aad10784c6d04fea4595d8c8ae68cc;hp=1f4e07b871d89e1c4b2a94b0faaef9a6319294b6;hpb=b33fd6859bbe71667bf9d8a6dbcaf62464bfbee5;p=sbcl.git diff --git a/BUGS b/BUGS index 1f4e07b..2c29d33 100644 --- a/BUGS +++ b/BUGS @@ -88,9 +88,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 @@ -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 @@ -258,7 +243,8 @@ WORKAROUND: 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~%")) @@ -281,6 +267,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, @@ -399,18 +387,6 @@ WORKAROUND: 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 @@ -466,11 +442,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 +463,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 +527,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 +624,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)) @@ -743,17 +697,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: 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 @@ -973,14 +916,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,64 +923,281 @@ 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: # + +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. + + 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 @@ -1060,3 +1212,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.