ANSI spec, bare 'MEMBER, 'AND, and 'OR are not legal types, CMUCL
(and now SBCL) interpret them as legal types.
-44:
- ANSI specifies DEFINE-SYMBOL-MACRO, but it's not defined in SBCL.
- CMU CL added it ca. Aug 13, 2000, after some discussion on the mailing
- list, and it is probably possible to use substantially the same
- patches to add it to SBCL.
-
45:
a slew of floating-point-related errors reported by Peter Van Eynde
on July 25, 2000:
c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something
it binds is declared SPECIAL inside.
-50:
- type system errors reported by Peter Van Eynde July 25, 2000:
- c: (SUBTYPEP '(INTEGER (0) (0)) 'NIL) dies with nested errors.
- d: In general, the system doesn't like '(INTEGER (0) (0)) -- it
- blows up at the level of SPECIFIER-TYPE with
- "Lower bound (0) is greater than upper bound (0)." Probably
- SPECIFIER-TYPE should return the NIL type instead.
- g: The type system isn't all that smart about relationships
- between hairy types, as shown in the type.erg test results,
- e.g. (SUBTYPEP 'CONS '(NOT ATOM)) => NIL, NIL.
-
51:
miscellaneous errors reported by Peter Van Eynde July 25, 2000:
a: (PROGN
The implementation of #'+ returns its single argument without
type checking, e.g. (+ "illegal") => "illegal".
-58:
- (SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH) => NIL, NIL
- Note: I looked into fixing this in 0.6.11.15, but gave up. The
- problem seems to be that there are two relevant type methods for
- the subtypep operation, HAIRY :COMPLEX-SUBTYPEP-ARG2 and
- INTERSECTION :COMPLEX-SUBTYPEP-ARG1, and only the first is
- called. This could be fixed, but type dispatch is messy and
- confusing enough already, I don't want to complicate it further.
- Perhaps someday we can make CLOS cross-compiled (instead of compiled
- after bootstrapping) so that we don't need to have the type system
- available before CLOS, and then we can rewrite the type methods to
- CLOS methods, and then expressing the solutions to stuff like this
- should become much more straightforward. -- WHN 2001-03-14
-
60:
The debugger LIST-LOCATIONS command doesn't work properly.
it should probably look at the class name, the way that it does
for STRUCTURE-OBJECTs.
-69:
- As reported by Martin Atzmueller on the sbcl-devel list 2000-11-22,
- > There remains one issue, that is a bug in SBCL:
- > According to my interpretation of the spec, the ":" and "@" modifiers
- > should appear _after_ the comma-seperated arguments.
- > Well, SBCL (and CMUCL for that matter) accept
- > (ASSERT (STRING= (FORMAT NIL "~:8D" 1) " 1"))
- > where the correct way (IMHO) should be
- > (ASSERT (STRING= (FORMAT NIL "~8:D" 1) " 1"))
- Probably SBCL should stop accepting the "~:8D"-style format arguments,
- or at least issue a warning.
-
70:
(probably related to bug #65; maybe related to bug #109)
The compiler doesn't like &OPTIONAL arguments in LABELS and FLET
it would decrease efficiency more than is probably necessary. Perhaps
using some sort of accept/reject method would be better.
-84:
- (SUBTYPEP '(SATISFIES SOME-UNDEFINED-FUN) NIL)=>NIL,T (should be NIL,NIL)
-
85:
Internally the compiler sometimes evaluates
(sb-kernel:type/= (specifier-type '*) (specifier-type t))
arguments in FLET/LABELS: it might be an old Python bug which is
only exercised by the new arrangement of the SBCL compiler.)
-132:
- Trying to compile
- (DEFUN FOO () (CATCH 0 (PRINT 1331)))
- gives an error
- #<SB-C:TN '0!1> is not valid as the second argument to VOP:
- SB-C:MAKE-CATCH-BLOCK,
- since the TN's primitive type SB-VM::POSITIVE-FIXNUM doesn't allow
- any of the SCs allowed by the operand restriction:
- (SB-VM::DESCRIPTOR-REG)
- The (CATCH 0 ...) construct is bad style (because of unportability
- of EQ testing of numbers) but it is legal, and shouldn't cause an
- internal compiler error. (This error occurs in sbcl-0.6.13 and in
- 0.pre7.86.flaky7.14.)
-
135:
Ideally, uninterning a symbol would allow it, and its associated
FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However,
T
T
+ This is probably due to underzealous clearing of the type caches; a
+ brute-force solution in that case would be to make a defclass expand
+ into something that included a call to SB-KERNEL::CLEAR-TYPE-CACHES,
+ but there may be a better solution.
+
141:
Pretty-printing nested backquotes doesn't work right, as
reported by Alexey Dejneka sbcl-devel 2002-01-13:
issues were cleaned up. As of sbcl-0.7.1.9, it occurs in
NODE-BLOCK called by LAMBDA-COMPONENT called by IR2-CONVERT-CLOSURE.
-149:
- (reported by Stig E Sandoe sbcl-devel 2002-02-02)
- In sbcl-0.7.1.13, compiling a DEFCLASS FOO form isn't enough to make
- the class known to the compiler for other forms compiled in the same
- file, so bogus warnings "undefined type: FOO" are generated, e.g.
- when compiling
- (in-package :cl-user)
- (defclass foo () ())
- (defun bar (x)
- (typep x 'foo))
+153:
+ (essentially the same problem as a CMU CL bug reported by Martin
+ Cracauer on cmucl-imp 2002-02-19)
+ There is a hole in structure slot type checking. Compiling and LOADing
+ (declaim (optimize safety))
+ (defstruct foo
+ (bla 0 :type fixnum))
+ (defun f ()
+ (let ((foo (make-foo)))
+ (setf (foo-bla foo) '(1 . 1))
+ (format t "Is ~a of type ~a a cons? => ~a~%"
+ (foo-bla foo)
+ (type-of (foo-bla foo))
+ (consp (foo-bla foo)))))
+ (f)
+ should signal an error, but in sbcl-0.7.1.21 instead gives the output
+ Is (1 . 1) of type CONS a cons? => NIL
+ without signalling an error.
+
+154:
+ There's some sort of problem with aborting back out of the debugger
+ after a %DETECT-STACK-EXHAUSTION error in sbcl-0.7.1.38. In some cases
+ telling the debugger to ABORT doesn't get you back to the main REPL,
+ but instead just gives you another stack exhaustion error. The problem
+ doesn't occur in the trivial case
+ * (defun frob () (frob) (frob))
+ FROB
+ * (frob)
+ but it has happened in more complicated cases (which I haven't
+ figured out how to reproduce).
+
+155:
+ Executing
+ (defclass standard-gadget (basic-gadget) ())
+ (defclass basic-gadget () ())
+ gives an error:
+ The slot SB-PCL::DIRECT-SUPERCLASSES is unbound in the
+ object #<SB-PCL::STANDARD-CLASS "unbound">.
+ (reported by Brian Spilsbury sbcl-devel 2002-04-09)
+
+156:
+ FUNCTION-LAMBDA-EXPRESSION doesn't work right in 0.7.0 or 0.7.2.9:
+ * (function-lambda-expression #'(lambda (x) x))
+ debugger invoked on condition of type TYPE-ERROR:
+ The value NIL is not of type SB-C::DEBUG-SOURCE
+ (reported by Alexey Dejneka sbcl-devel 2002-04-12)
+
+157:
+ Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and
+ UPGRADED-COMPLEX-PART-TYPE should have an optional environment argument.
+ (reported by Alexey Dejneka sbcl-devel 2002-04-12)
+
+158:
+ Compiling the following code causes SBCL 0.7.2 to bug. This only
+ happens with optimization enabled, and only when the loop variable is
+ being incremented by more than 1.
+ (defun foo (array)
+ (declare (optimize (safety 0) (space 0) (debug 0) (speed 3)))
+ (loop for i from 0 to 10 by 2
+ do (foo (svref array i))) (svref array (1+ i)))
+ (reported by Eric Marsden sbcl-devel 2002-04-15)
+
+162:
+ (reported by Robert E. Brown 2002-04-16)
+ When a function is called with too few arguments, causing the
+ debugger to be entered, the uninitialized slots in the bad call frame
+ seem to cause GCish problems, being interpreted as tagged data even
+ though they're not. In particular, executing ROOM in the
+ debugger at that point causes AVER failures:
+ * (machine-type)
+ "X86"
+ * (lisp-implementation-version)
+ "0.7.2.12"
+ * (typep 10)
+ ...
+ 0] (room)
+ ...
+ failed AVER: "(SAP= CURRENT END)"
+ (Christophe Rhodes reports that this doesn't occur on the SPARC, which
+ isn't too surprising since there are many differences in stack
+ implementation and GC conservatism between the X86 and other ports.)
+
+163:
+ HOST-NAMESTRING on a Unix pathname returns "Unix", which isn't
+ treated as a valid host by anything else in the system. (Reported by
+ Erik Naggum on comp.lang.lisp 2002-04-18)
DEFUNCT CATEGORIES OF BUGS
IR1-#:
- These numbers were used for bugs related to the old IR1
- interpreter. The # values reached 6 before the category
- was closed down.
\ No newline at end of file
+ These labels were used for bugs related to the old IR1 interpreter.
+ The # values reached 6 before the category was closed down.
projects / sbcl.git / blobdiff