X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=0c6e139c2fed4d4149f2ea177d4defa75a0a2119;hb=faba0f9a5c990ea378e53f995acf9cdf3258c412;hp=78b9bf58207445fdb95432b52cac209c8a6ffb7e;hpb=46ca19e3db3fc054743290cdf6e1cc51ff3ec588;p=sbcl.git diff --git a/BUGS b/BUGS index 78b9bf5..0c6e139 100644 --- a/BUGS +++ b/BUGS @@ -77,13 +77,6 @@ WORKAROUND: Such code should compile without complaint and work correctly either on SBCL or on any other completely compliant Common Lisp system. - b: &AUX argument in a boa-constructor without a default value means - "do not initilize this slot" and does not cause type error. But - an error may be signalled at read time and it would be good if - SBCL did it. - - d: (fixed in 0.8.1.5) - 33: And as long as we're wishing, it would be awfully nice if INSPECT could also report on closures, telling about the values of the bound variables. @@ -347,28 +340,6 @@ WORKAROUND: forever, even when it is uninterned and all other references to it are lost. -143: - (reported by Jesse Bouwman 2001-10-24 through the unfortunately - prominent SourceForge web/db bug tracking system, which is - unfortunately not a reliable way to get a timely response from - the SBCL maintainers) - In the course of trying to build a test case for an - application error, I encountered this behavior: - If you start up sbcl, and then lay on CTRL-C for a - minute or two, the lisp process will eventually say: - %PRIMITIVE HALT called; the party is over. - and throw you into the monitor. If I start up lisp, - attach to the process with strace, and then do the same - (abusive) thing, I get instead: - access failure in heap page not marked as write-protected - and the monitor again. I don't know enough to have the - faintest idea of what is going on here. - This is with sbcl 6.12, uname -a reports: - Linux prep 2.2.19 #4 SMP Tue Apr 24 13:59:52 CDT 2001 i686 unknown - I (WHN) have verified that the same thing occurs on sbcl-0.pre7.141 - under OpenBSD 2.9 on my X86 laptop. Do be patient when you try it: - it took more than two minutes (but less than five) for me. - 145: a. ANSI allows types `(COMPLEX ,FOO) to use very hairy values for @@ -626,25 +597,6 @@ WORKAROUND: This is probably the same bug as 162 -235: "type system and inline expansion" - a. - (declaim (ftype (function (cons) number) acc)) - (declaim (inline acc)) - (defun acc (c) - (the number (car c))) - - (defun foo (x y) - (values (locally (declare (optimize (safety 0))) - (acc x)) - (locally (declare (optimize (safety 3))) - (acc y)))) - - (foo '(nil) '(t)) => NIL, T. - - As of 0.9.15.41 this seems to be due to ACC being inlined only once - inside FOO, which results in the second call reusing the FUNCTIONAL - resulting from the first -- which doesn't check the type. - 237: "Environment arguments to type functions" a. Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and UPGRADED-COMPLEX-PART-TYPE now have an optional environment @@ -655,32 +607,6 @@ WORKAROUND: calls of the form (TYPEP 1 'INTEGER NIL), even though this is just as optimizeable as (TYPEP 1 'INTEGER). -238: "REPL compiler overenthusiasm for CLOS code" - From the REPL, - * (defclass foo () ()) - * (defmethod bar ((x foo) (foo foo)) (call-next-method)) - causes approximately 100 lines of code deletion notes. Some - discussion on this issue happened under the title 'Three "interesting" - bugs in PCL', resulting in a fix for this oververbosity from the - compiler proper; however, the problem persists in the interactor - because the notion of original source is not preserved: for the - compiler, the original source of the above expression is (DEFMETHOD - BAR ((X FOO) (FOO FOO)) (CALL-NEXT-METHOD)), while by the time the - compiler gets its hands on the code needing compilation from the REPL, - it has been macroexpanded several times. - - A symptom of the same underlying problem, reported by Tony Martinez: - * (handler-case - (with-input-from-string (*query-io* " no") - (yes-or-no-p)) - (simple-type-error () 'error)) - ; in: LAMBDA NIL - ; (SB-KERNEL:FLOAT-WAIT) - ; - ; note: deleting unreachable code - ; compilation unit finished - ; printed 1 note - 242: "WRITE-SEQUENCE suboptimality" (observed from clx performance) In sbcl-0.7.13, WRITE-SEQUENCE of a sequence of type @@ -1223,21 +1149,6 @@ WORKAROUND: conditionalization and OAOOMization: refactoring the common parts would be good. -354: XEPs in backtraces - Under default compilation policy - (defun test () - (throw :unknown t)) - (test) - Has the XEP for TEST in the backtrace, not the TEST frame itself. - (sparc and x86 at least) - - Since SBCL 0.8.20.1 this is hidden unless *SHOW-ENTRY-POINT-DETAILS* - is true (instead there appear two TEST frames at least on ppc). The - underlying cause seems to be that SB-C::TAIL-ANNOTATE will not merge - the tail-call for the XEP, since Python has by that time proved that - the function can never return; same happens if the function holds an - unconditional call to ERROR. - 356: PCL corruption (reported by Bruno Haible) After the "layout depth conflict" error, the CLOS is left in a state where @@ -1268,52 +1179,6 @@ WORKAROUND: (make-instance 'bar) ] -357: defstruct inheritance of initforms - (reported by Bruno Haible) - When defstruct and defclass (with :metaclass structure-class) are mixed, - 1. some slot initforms are ignored by the DEFSTRUCT generated constructor - function, and - 2. all slot initforms are ignored by MAKE-INSTANCE. (This can be arguably - OK for initforms that were given in a DEFSTRUCT form, but for those - given in a DEFCLASS form, I think it qualifies as a bug.) - Test case: - (defstruct structure02a - slot1 - (slot2 t) - (slot3 (floor pi))) - (defclass structure02b (structure02a) - ((slot4 :initform -44) - (slot5) - (slot6 :initform t) - (slot7 :initform (floor (* pi pi))) - (slot8 :initform 88)) - (:metaclass structure-class)) - (defstruct (structure02c (:include structure02b (slot8 -88))) - slot9 - (slot10 t) - (slot11 (floor (exp 3)))) - ;; 1. Form: - (let ((a (make-structure02c))) - (list (structure02c-slot4 a) - (structure02c-slot5 a) - (structure02c-slot6 a) - (structure02c-slot7 a))) - Expected: (-44 nil t 9) - Got: (SB-PCL::..SLOT-UNBOUND.. SB-PCL::..SLOT-UNBOUND.. - SB-PCL::..SLOT-UNBOUND.. SB-PCL::..SLOT-UNBOUND..) - ;; 2. Form: - (let ((b (make-instance 'structure02c))) - (list (structure02c-slot2 b) - (structure02c-slot3 b) - (structure02c-slot4 b) - (structure02c-slot6 b) - (structure02c-slot7 b) - (structure02c-slot8 b) - (structure02c-slot10 b) - (structure02c-slot11 b))) - Expected: (t 3 -44 t 9 -88 t 20) - Got: (0 0 0 0 0 0 0 0) - 359: wrong default value for ensure-generic-function's :generic-function-class argument (reported by Bruno Haible) ANSI CL is silent on this, but the MOP's specification of ENSURE-GENERIC-FUNCTION says: @@ -1483,20 +1348,6 @@ WORKAROUND: (FOO 1 2) gives NO-APPLICABLE-METHOD rather than an argument count error. -395: Unicode and streams - One of the remaining problems in SBCL's Unicode support is the lack - of generality in certain streams. - a. FILL-POINTER-STREAMs: SBCL refuses to write (e.g. using FORMAT) - to streams made from strings that aren't character strings with - fill-pointers: - (let ((v (make-array 5 :fill-pointer 0 :element-type 'standard-char))) - (format v "foo") - v) - should return a non-simple base string containing "foo" but - instead errors. - - (reported on sbcl-help by "tichy") - 396: block-compilation bug (let ((x 1)) (dotimes (y 10) @@ -1598,17 +1449,6 @@ WORKAROUND: perhaps because CLISP has shuffled the clauses into an ANSI-compliant order before proceeding. -405: a TYPE-ERROR in MERGE-LETS exercised at DEBUG 3 - In sbcl-0.9.16.21 on linux/86, compiling - (declaim (optimize (debug 3))) - (defstruct foo bar) - (let () - (flet ((i (x) (frob x (foo-bar foo)))) - (i :five))) - causes a TYPE-ERROR - The value NIL is not of type SB-C::PHYSENV. - in MERGE-LETS. - 406: functional has external references -- failed aver Given the following food in a single file (eval-when (:compile-toplevel :load-toplevel :execute)