X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=0a80569a59ecc580b826eb4b24892c785024bab5;hb=71173fc4590389c52ac0e1abd75f79e417dad361;hp=ca875a7563839e03bc861fc96cb7ee9ce227c5ef;hpb=b08344ddbb8d0193054b72c01be7e367422ccf03;p=sbcl.git diff --git a/BUGS b/BUGS index ca875a7..0a80569 100644 --- a/BUGS +++ b/BUGS @@ -22,45 +22,24 @@ but instead the program loops endlessly instead of printing the object. -KNOWN BUGS RELATED TO THE IR1 INTERPRETER +NOTES: -(Note: At some point, the 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 go away automatically. Until then, -they'll probably remain, since they're not considered urgent. -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.) +There is also some information on bugs in the manual page and +in the TODO file. Eventually more such information may move here. -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 +The gaps in the number sequence belong to old bugs which have been +fixed. KNOWN BUGS OF NO SPECIAL CLASS: -(Note: - * There is also some information on bugs in the manual page and - in the TODO file. Eventually more such information may move here. - * The gaps in the number sequence belong to old bugs which were - eliminated.) - 2: DEFSTRUCT should almost certainly overwrite the old LAYOUT information instead of just punting when a contradictory structure definition - is loaded. + 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: It should cause a STYLE-WARNING, not a full WARNING, when a structure @@ -78,7 +57,7 @@ KNOWN BUGS OF NO SPECIAL CLASS: 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)) + (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. @@ -277,15 +256,6 @@ becomes FASL: DTC's recommended workaround from the mailing list 3 Mar 2000: (setf (pcl::find-class 'ccc1) (pcl::find-class 'ccc)) -21: - 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" - 22: 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 @@ -350,16 +320,6 @@ returning an array as first value always. Process inferior-lisp exited abnormally with code 1 I haven't noticed a repeatable case of this yet. -28: - 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. - 29: some sort of bug in inlining and RETURN-FROM in sbcl-0.6.5: Compiling (DEFUN BAR? (X) @@ -517,6 +477,24 @@ returning an array as first value always. confused and compiles a full call to %INSTANCE-TYPEP (which doesn't exist as a function) instead. +37a: + The %INSTANCE-TYPEP problem in bug 37 comes up also when compiling + and loading + (IN-PACKAGE :CL-USER) + (LOCALLY + (DECLARE (OPTIMIZE (SAFETY 3) (SPEED 2) (SPACE 2))) + (DECLAIM (FTYPE (FUNCTION (&REST T) (VALUES)) EMPTYVALUES)) + (DEFUN EMPTYVALUES (&REST REST) + (DECLARE (IGNORE REST)) + (VALUES)) + (DEFSTRUCT DUMMYSTRUCT X Y) + (DEFUN FROB-EMPTYVALUES (X) + (LET ((RES (EMPTYVALUES X X X))) + (UNLESS (TYPEP RES 'DUMMYSTRUCT) + 'EXPECTED-RETURN-VALUE)))) + (ASSERT (EQ (FROB-EMPTYVALUES 11) 'EXPECTED-RETURN-VALUE)) + + 38: DEFMETHOD doesn't check the syntax of &REST argument lists properly, accepting &REST even when it's not followed by an argument name: @@ -758,3 +736,111 @@ Error in function C::GET-LAMBDA-TO-COMPILE: (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)). + + +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. + +IR1-4: + 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.]