or on the development mailing list
sbcl-devel@lists.sourceforge.net
-Please please please include enough information in a bug report
-that someone reading it can reproduce the problem, i.e. don't write
+Please include enough information in a bug report that someone reading
+it can reproduce the problem, i.e. don't write
Subject: apparent bug in PRINT-OBJECT (or *PRINT-LENGTH*?)
PRINT-OBJECT doesn't seem to work with *PRINT-LENGTH*. Is this a bug?
but instead
the program loops endlessly instead of printing the object.
-KNOWN BUGS RELATED TO THE IR1 INTERPRETER
-
-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.
-
-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
+NOTES:
+There is also some information on bugs in the manual page and
+in the TODO file. Eventually more such information may move here.
-OTHER KNOWN BUGS:
+The gaps in the number sequence belong to old bugs which have been
+fixed.
-(There is also some information on bugs in the manual page and in the
-TODO file. Eventually more such information may move here.)
-1:
- Failure in initialization files is not handled gracefully -- it's
- a throw to TOP-LEVEL-CATCHER, which is not caught until we enter
- TOPLEVEL-REPL. Code should be added to catch such THROWs even when
- we're not in TOPLEVEL-REPL and do *something* with them (probably
- complaining about an error outside TOPLEVEL-REPL, perhaps printing
- a BACKTRACE, then terminating execution of SBCL).
+KNOWN BUGS OF NO SPECIAL CLASS:
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
specifically required by the ANSI spec.)
4:
- It should cause a STYLE-WARNING, not a WARNING, when the system ignores
+ It should cause a note, not a WARNING, when the system ignores
an FTYPE proclamation for a slot accessor.
5:
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.
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" <dtc@jeack.com.au>
-
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
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:
b: READ should probably return READER-ERROR, not the bare
arithmetic error, when input a la "1/0" or "1e1000" causes
an arithmetic error.
- c: (BUTLAST NIL) should return NIL. (This appears to be a compiler
- bug, since the definition of BUTLAST, when interpreted, does
- give (BUTLAST NIL)=>NIL.)
52:
It has been reported (e.g. by Peter Van Eynde) that there are
Error in function C::GET-LAMBDA-TO-COMPILE:
#<Closure Over Function "DEFUN (SETF MACRO-FUNCTION)" {480E21B1}> was defined in a non-null environment.
-57:
- In sbcl-0.6.7, the compiler accepted a bogus declaration
- (TYPE INDEX LENGTH) in the definition of BUTLAST, and then died
- with infinite regress of errors when the BUTLAST function was
- executed with a LIST=NIL which would cause LENGTH to be -1.
- I fixed the bogus declaration, but I should come back and see
- whether the system's inability to recover from the bogus declaration
- (by signalling a TYPE-ERROR and dropping into the debugger) was
- a compiler problem which remains to be fixed, or one of the
- unrelated infinite-regress-errors problems, many related to
- revised signal handling, which were fixed around the same time.
-
58:
(SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH)
=> NIL, NIL
60:
The debugger LIST-LOCATIONS command doesn't work properly.
+
+61:
+ Compiling and loading
+ (DEFUN FAIL (X) (THROW 'FAIL-TAG X))
+ (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.
projects / sbcl.git / blobdiff