(let ((x (1+ x)))
(call-next-method)))
Now (FOO 3) should return 3, but instead it returns 4.
-
-137:
- (SB-DEBUG:BACKTRACE) output should start with something
- including the name BACKTRACE, not (as in 0.pre7.88)
- just "0: (\"hairy arg processor\" ...)". Until about
- sbcl-0.pre7.109, the names in BACKTRACE were all screwed
- up compared to the nice useful names in sbcl-0.6.13.
- Around sbcl-0.pre7.109, they were mostly fixed by using
- NAMED-LAMBDA to implement DEFUN. However, there are still
- some screwups left, e.g. as of sbcl-0.pre7.109, there are
- still some functions named "hairy arg processor" and
- "SB-INT:&MORE processor".
+
+140:
+ (reported by Alexey Dejneka sbcl-devel 2002-01-03)
+
+ SUBTYPEP does not work well with redefined classes:
+ ---
+ * (defclass a () ())
+ #<STANDARD-CLASS A>
+ * (defclass b () ())
+ #<STANDARD-CLASS B>
+ * (subtypep 'b 'a)
+ NIL
+ T
+ * (defclass b (a) ())
+ #<STANDARD-CLASS B>
+ * (subtypep 'b 'a)
+ T
+ T
+ * (defclass b () ())
+ #<STANDARD-CLASS B>
+
+ ;;; And now...
+ * (subtypep 'b 'a)
+ T
+ T
+
+ This bug was fixed in sbcl-0.7.4.1 by invalidating the PCL wrapper
+ class upon redefinition. Unfortunately, doing so causes bug #176 to
+ appear. Pending further investication, one or other of these bugs
+ might be present at any given time.
141:
Pretty-printing nested backquotes doesn't work right, as
(defclass c0 (b) ())
(make-instance 'c19)
-177:
- reported by Stig E Sandoe 8 Jun 2002 on sbcl-devel:
- ;;; I am a bit unsure about SBCL's warnings with some of my code.
- ;;; ASDF seems to die on warnings and SBCL seems to generate one
- ;;; out of nothing. I've tried to turn it into an example
- ;;; (that can be LOADed or COMPILEd to reproduce warnings):
- (in-package :cl-user)
- (defclass a () ())
- (defclass b () ())
- (defclass c (b) ())
- (defgeneric get-price (obj1 obj2))
- (defmethod get-price (obj1 obj2)
- 0)
- (defmethod get-price ((obj1 a) (obj2 b))
- 20)
- (defmethod get-price ((obj1 a) (obj2 c))
- (* 3 (call-next-method)))
- (print (get-price (make-instance 'a) (make-instance 'c)))
- ;;; In the GET-PRICE where I call CALL-NEXT-METHOD, it starts to
- ;;; generate real WARNINGS:
- ;;; stig@palomba(9:02)[~] 690> sbcl
- ;;; This is SBCL 0.7.4, an implementation of ANSI Common Lisp.
- ;;; ...
- ;;; * (load "call-next")
- ;;; ; in: LAMBDA NIL
- ;;; ; (CALL-NEXT-METHOD)
- ;;; ; --> SB-PCL::CALL-NEXT-METHOD-BODY IF IF
- ;;; ; --> SB-PCL::INVOKE-EFFECTIVE-METHOD-FUNCTION LOCALLY COND IF COND IF
- ;;; PROGN
- ;;; ; --> LET WHEN COND IF PROGN SETF LET* MULTIPLE-VALUE-BIND LET FUNCALL
- ;;; ; --> SB-C::%FUNCALL BLOCK SETF SB-KERNEL:%SVSET SB-KERNEL:%ASET LET*
- ;;; ; --> SB-KERNEL:HAIRY-DATA-VECTOR-SET MULTIPLE-VALUE-BIND
- ;;; MULTIPLE-VALUE-CALL
- ;;; ; --> FUNCTION
- ;;; ; ==>
- ;;; ; (SB-KERNEL:DATA-VECTOR-SET (TRULY-THE (SIMPLE-ARRAY T 1) ARRAY)
- ;;; ; SB-INT:INDEX
- ;;; ; SB-C::NEW-VALUE)
- ;;; ;
- ;;; ; caught WARNING:
- ;;; ; Result is a A, not a NUMBER.
- ;;; ...
- ;;; ; compilation unit finished
- ;;; ; caught 4 WARNING conditions
+ See also bug #140.
+
+178: "AVER failure compiling confused THEs in FUNCALL"
+ In sbcl-0.7.4.24, compiling
+ (defun bug178 (x)
+ (funcall (the function (the standard-object x))))
+ gives
+ failed AVER:
+ "(AND (EQ (IR2-CONTINUATION-PRIMITIVE-TYPE 2CONT) FUNCTION-PTYPE) (EQ CHECK T))"
+ This variant compiles OK, though:
+ (defun bug178alternative (x)
+ (funcall (the nil x)))
+181: "bad type specifier drops compiler into debugger"
+ Compiling
+ (in-package :cl-user)
+ (defun bar (x)
+ (declare (type 0 x))
+ (cons x x))
+ signals
+ bad thing to be a type specifier: 0
+ which seems fine, but also enters the debugger (instead of having
+ the compiler handle the error, convert it into a COMPILER-ERROR, and
+ continue compiling) which seems wrong.
+
+182: "SPARC/Linux floating point"
+ Evaluating (/ 1.0 0.0) at the prompt causes a Bus error and complete
+ death of the environment. Other floating point operations sometimes
+ return infinities when they should raise traps (e.g. the test case
+ for bug #146, (expt 2.0 12777)).
+
+183: "IEEE floating point issues"
+ Even where floating point handling is being dealt with relatively
+ well (as of sbcl-0.7.5, on sparc/sunos and alpha; see bug #146), the
+ accrued-exceptions and current-exceptions part of the fp control
+ word don't seem to bear much relation to reality. E.g. on
+ SPARC/SunOS:
+ * (/ 1.0 0.0)
+
+ debugger invoked on condition of type DIVISION-BY-ZERO:
+ arithmetic error DIVISION-BY-ZERO signalled
+ 0] (sb-vm::get-floating-point-modes)
+
+ (:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO)
+ :ROUNDING-MODE :NEAREST
+ :CURRENT-EXCEPTIONS NIL
+ :ACCRUED-EXCEPTIONS (:INEXACT)
+ :FAST-MODE NIL)
+ 0] abort
+ * (sb-vm::get-floating-point-modes)
+ (:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO)
+ :ROUNDING-MODE :NEAREST
+ :CURRENT-EXCEPTIONS (:INEXACT)
+ :ACCRUED-EXCEPTIONS (:INEXACT)
+ :FAST-MODE NIL)
DEFUNCT CATEGORIES OF BUGS
IR1-#:
projects / sbcl.git / blobdiff