X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=e50ba7321a1ea24d0198a43c9a2abc532ab166c6;hb=f9d6d21a7f54638292214ceb9886edc03b99d545;hp=534c9998450cf8070b98d36811293001b2021e18;hpb=eafc55e040c41a5fc4215d364f2b2b3bbf545810;p=sbcl.git diff --git a/BUGS b/BUGS index 534c999..e50ba73 100644 --- a/BUGS +++ b/BUGS @@ -50,31 +50,33 @@ WORKAROUND: believers in ANSI compatibility and all, (1) there's no obvious simple way to do it (short of disabling all warnings for type mismatches everywhere), and (2) there's a good portable - workaround. ANSI justifies this specification by saying + workaround, and (3) by their own reasoning, it looks as though + ANSI may have gotten it wrong. ANSI justifies this specification + by saying The restriction against issuing a warning for type mismatches between a slot-initform and the corresponding slot's :TYPE option is necessary because a slot-initform must be specified in order to specify slot options; in some cases, no suitable default may exist. - In SBCL, as in CMU CL (or, for that matter, any compiler which - really understands Common Lisp types) a suitable default does - exist, in all cases, because the compiler understands the concept - of functions which never return (i.e. has return type NIL, e.g. - ERROR). Thus, as a portable workaround, you can use a call to - some known-never-to-return function as the default. E.g. + However, in SBCL (as in CMU CL or, for that matter, any compiler + which really understands Common Lisp types) a suitable default + does exist, in all cases, because the compiler understands the + concept of functions which never return (i.e. has return type NIL). + Thus, as a portable workaround, you can use a call to some + known-never-to-return function as the default. E.g. (DEFSTRUCT FOO (BAR (ERROR "missing :BAR argument") :TYPE SOME-TYPE-TOO-HAIRY-TO-CONSTRUCT-AN-INSTANCE-OF)) or - (DECLAIM (FTYPE () NIL) MISSING-ARG) + (DECLAIM (FTYPE (FUNCTION () NIL) MISSING-ARG)) (DEFUN REQUIRED-ARG () ; workaround for SBCL non-ANSI slot init typing (ERROR "missing required argument")) (DEFSTRUCT FOO (BAR (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT) (BLETCH (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT) (N-REFS-SO-FAR 0 :TYPE (INTEGER 0))) - Such code will compile without complaint and work correctly either - on SBCL or on a completely compliant Common Lisp system. + Such code should compile without complaint and work correctly either + on SBCL or on any other completely compliant Common Lisp system. 6: bogus warnings about undefined functions for magic functions like @@ -1135,14 +1137,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: structure classes related by inheritance. As of 0.7.0, SBCL still doesn't follow it. -128: - READ-SEQUENCE doesn't work for Gray streams. (reported by Nathan - Froyd sbcl-devel 2001-10-15) As per subsequent discussion on the - list, the Gray streams proposal doesn't mention READ-SEQUENCE and - WRITE-SEQUENCE because it predates them, generalizing it to - cover them is an obvious extension, ACL does it, and there's a - patch for for CMU CL which does it too. - 129: insufficient syntax checking in MACROLET: (defun foo (x) @@ -1257,16 +1251,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: types manually, allowing the special case (VALUES) but still excluding all more-complex VALUES types. -134: - (reported by Alexey Dejneka sbcl-devel 2001-12-07) - (let ((s '((1 2 3)))) - (eval (eval ``(vector ,@',@s)))) - - should return #(1 2 3), instead of this it causes a reader error. - - Interior call of BACKQUOTIFY erroneously optimizes ,@': it immediately - splices the temporal representation of ,@S. - 135: Ideally, uninterning a symbol would allow it, and its associated FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However, @@ -1289,40 +1273,99 @@ Error in function C::GET-LAMBDA-TO-COMPILE: 137: (SB-DEBUG:BACKTRACE) output should start with something including the name BACKTRACE, not (as in 0.pre7.88) - just "0: (\"hairy arg processor\" ...)". In general - the names in BACKTRACE are all screwed up compared to - the nice useful names in 0.6.13. - - Note for those who observe that this is an annoying - bug and doesn't belong in a release: See the "note for the - ambitious", below. - - Note for the ambitious: This is an important bug and I'd - really like to fix it and spent many hours on it. The - obvious ways to fix it are hard, because the underlying - infrastructure seems to be rather broken. - * There are two mostly-separate systems for storing names, - the in-the-function-object system used by e.g. - CL:FUNCTION-LAMBDA-EXPRESSION and the - in-the-DEBUG-FUN-object system used by e.g. BACKTRACE. - The code as of sbcl-0.pre7.94 is smart enough to set - up the first value, but not the second (because I naively - assumed that one mechanism is enough, and didn't proof - read the entire system to see whether there might be - another mechanism?! argh...) - * The systems are not quite separate, but instead weirdly and - fragilely coupled by the FUN-DEBUG-FUN algorithm. - * If you try to refactor this dain bramage away, reducing - things to a single system -- I tried to add a - %SIMPLE-FUN-DEBUG-FUN slot, planning eventually to get - rid of the old %SIMPLE-FUN-NAME slot in favor of indirection - through the new slot -- you get torpedoed by the fragility - of the SIMPLE-FUN primitive object. Just adding the - new slot, without making any other changes in the system, - is enough to make the system fail with what look like - memory corruption problems in warm init. - But please do fix some or all of the problem, I'm tired - of messing with it. -- WHN 2001-12-22 + 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". + +138: + a pair of cross-compiler bugs in sbcl-0.pre7.107 + +138a: + $ cat > /tmp/bug138.lisp << EOF + (in-package "SB!KERNEL") + (defun f-c-l (name parent-types) + (let* ((cpl (mapcar (lambda (x) + (condition-class-cpl x)) + parent-types)) + (new-inherits + (concatenate 'simple-vector + (layout-inherits cond-layout)))) + (if (not (mismatch (layout-inherits olayout) new-inherits)) + olayout + (make-layout)))) + EOF + $ sbcl --core output/after-xc.core + ... + * (target-compile-file "/tmp/bug138.lisp") + ... + internal error, failed AVER: + "(COMMON-LISP:MEMBER SB!C::FUN (SB!C::COMPONENT-LAMBDAS SB!C:COMPONENT))" + + It seems as though this xc bug is likely to correspond to a bug in the + ordinary compiler, but I haven't yet found a test case which causes + this problem in the ordinary compiler. + + related weirdness: Using #'(LAMBDA (X) ...) instead of (LAMBDA (X) ...) + makes the assertion failure go away. + +138b: + Even when you relax the AVER that fails in 138a, there's another + problem cross-compiling the same code: + internal error, failed AVER: + "(COMMON-LISP:ZEROP + (COMMON-LISP:HASH-TABLE-COUNT + (SB!FASL::FASL-OUTPUT-PATCH-TABLE SB!FASL:FASL-OUTPUT)))" + + The same problem appears in the simpler test case + (in-package "SB!KERNEL") + (defun f-c-l () + (let ((cpl (foo (lambda (x) + (condition-class-cpl x)))) + (new-inherits (layout-inherits cond-layout))) + (layout-inherits olayout))) + + Changing CONDITION-CLASS-CPL or (either of the calls to) LAYOUT-INHERITS + to arbitrary nonmagic not-defined-yet just-do-a-full-call functions makes + the problem go away. Also, even in this simpler test case which fails + on a very different AVER, the 138a weirdness about s/(lambda/#'(lambda/ + making the problem go away is preserved. + + I still haven't found any way to make this happen in the ordinary + (not cross-) SBCL compiler, nor in CMU CL. + +138c: + In sbcl-0.pre7.111 I added an assertion upstream, in IR2-CONVERT-CLOSURE, + which fails for the test case above but doesn't keep the system + from cross-compiling itself or passing its tests. + +139: + In sbcl-0.pre7.107, (DIRECTORY "*.*") is broken, as reported by + Nathan Froyd sbcl-devel 2001-12-28. + + Christophe Rhodes suggested (sbcl-devel 2001-12-30) converting + the MERGED-PATHNAME expression in DEFUN DIRECTORY to + (merged-pathname (merge-pathnames pathname + *default-pathname-defaults*)) + This looks right, and fixes this bug, but it interacts with the NODES + logic in %ENUMERATE-PATHNAMES to create a new bug, so that + (DIRECTORY "../**/*.*") no longer shows files in the current working + directory. Probably %ENUMERATE-PATHNAMES (or related logic like + %ENUMERATE-MATCHES) needs to be patched as well. + + Note: The MERGED-PATHNAME change changes behavior incompatibly, + making e.g. (DIRECTORY "*") no longer equivalent to (DIRECTORY "*.*"), + so deserves a NEWS entry. E.g. +* minor incompatible change (part of a bug fix by Christophe Rhodes + to DIRECTORY behavior): DIRECTORY no longer implicitly promotes + NIL slots of its pathname argument to :WILD, and in particular + asking for the contents of a directory, which you used to be able + to do without explicit wildcards, e.g. (DIRECTORY "/tmp/"), + now needs explicit wildcards, e.g. (DIRECTORY "/tmp/*.*"). KNOWN BUGS RELATED TO THE IR1 INTERPRETER