+122:
+ There was some sort of screwup in handling of
+ (IF (NOT (IGNORE-ERRORS ..))). E.g.
+ (defun foo1i ()
+ (if (not (ignore-errors
+ (make-pathname :host "foo" :directory "!bla" :name "bar")))
+ (print "ok")
+ (error "notunlessnot")))
+ The (NOT (IGNORE-ERRORS ..)) form evaluates to T, so this should be
+ printing "ok", but instead it's going to the ERROR. This problem
+ seems to've been introduced by MNA's HANDLER-CASE patch (sbcl-devel
+ 2001-07-17) and as a workaround (put in sbcl-0.pre7.14.flaky4.12)
+ I reverted back to the old weird HANDLER-CASE code. However, I
+ think the problem looks like a compiler bug in handling RETURN-FROM,
+ so I left the MNA-patched code in HANDLER-CASE (suppressed with
+ #+NIL) and I'd like to go back to see whether this really is
+ a compiler bug before I delete this BUGS entry.
+
+123:
+ The *USE-IMPLEMENTATION-TYPES* hack causes bugs, particularly
+ (IN-PACKAGE :SB-KERNEL)
+ (TYPE= (SPECIFIER-TYPE '(VECTOR T))
+ (SPECIFIER-TYPE '(VECTOR UNDEFTYPE)))
+ Then because of this, the compiler bogusly optimizes
+ (TYPEP #(11) '(SIMPLE-ARRAY UNDEF-TYPE 1))
+ to T. Unfortunately, just setting *USE-IMPLEMENTATION-TYPES* to
+ NIL around sbcl-0.pre7.14.flaky4.12 didn't work: the compiler complained
+ about type mismatches (probably harmlessly, another instance of bug 117);
+ and then cold init died with a segmentation fault.
+
+124:
+ As of version 0.pre7.14, SBCL's implementation of MACROLET makes
+ the entire lexical environment at the point of MACROLET available
+ in the bodies of the macroexpander functions. In particular, it
+ allows the function bodies (which run at compile time) to try to
+ access lexical variables (which are only defined at runtime).
+ It doesn't even issue a warning, which is bad.
+
+ The SBCL behavior arguably conforms to the ANSI spec (since the
+ spec says that the behavior is undefined, ergo anything conforms).
+ However, it would be better to issue a compile-time error.
+ Unfortunately I (WHN) don't see any simple way to detect this
+ condition in order to issue such an error, so for the meantime
+ SBCL just does this weird broken "conforming" thing.
+
+ The ANSI standard says, in the definition of the special operator
+ MACROLET,
+ The macro-expansion functions defined by MACROLET are defined
+ in the lexical environment in which the MACROLET form appears.
+ Declarations and MACROLET and SYMBOL-MACROLET definitions affect
+ the local macro definitions in a MACROLET, but the consequences
+ are undefined if the local macro definitions reference any
+ local variable or function bindings that are visible in that
+ lexical environment.
+ Then it seems to contradict itself by giving the example
+ (defun foo (x flag)
+ (macrolet ((fudge (z)
+ ;The parameters x and flag are not accessible
+ ; at this point; a reference to flag would be to
+ ; the global variable of that name.
+ ` (if flag (* ,z ,z) ,z)))
+ ;The parameters x and flag are accessible here.
+ (+ x
+ (fudge x)
+ (fudge (+ x 1)))))
+ The comment "a reference to flag would be to the global variable
+ of the same name" sounds like good behavior for the system to have.
+ but actual specification quoted above says that the actual behavior
+ is undefined.
+
+125:
+ (as reported by Gabe Garza on cmucl-help 2001-09-21)
+ (defvar *tmp* 3)
+ (defun test-pred (x y)
+ (eq x y))
+ (defun test-case ()
+ (let* ((x *tmp*)
+ (func (lambda () x)))
+ (print (eq func func))
+ (print (test-pred func func))
+ (delete func (list func))))
+ Now calling (TEST-CASE) gives output
+ NIL
+ NIL
+ (#<FUNCTION {500A9EF9}>)
+ Evidently Python thinks of the lambda as a code transformation so
+ much that it forgets that it's also an object.
+
+126:
+ (fixed in 0.pre7.41)
+
+127:
+ The DEFSTRUCT section of the ANSI spec, in the :CONC-NAME section,
+ specifies a precedence rule for name collisions between slot accessors of
+ structure classes related by inheritance. As of 0.7.0, SBCL still
+ doesn't follow it.
+
+129:
+ insufficient syntax checking in MACROLET:
+ (defun foo (x)
+ (macrolet ((defmacro bar (z) `(+ z z)))
+ (bar x)))
+ shouldn't compile without error (because of the extra DEFMACRO symbol).
+
+130:
+ reported by Alexey Dejneka on sbcl-devel 2001-11-03
+ (defun x (x)
+ "Return X if X is a non-negative integer."
+ (let ((step (lambda (%funcall)
+ (lambda (n)
+ (cond ((= n 0) 0)
+ (t (1+ (funcall %funcall (1- n)))))))))
+ (funcall
+ ((lambda (a)
+ (funcall step (lambda (n)
+ (funcall (funcall a a) n))))
+ (lambda (a)
+ (funcall step (lambda (n)
+ (funcall (funcall a a) n)))))
+ x)))
+ This function returns its argument. But after removing percents it
+ does not work: "Result of (1- n) is not a function".
+
+131:
+ As of sbcl-0.pre7.86.flaky7.3, the cross-compiler, and probably
+ the CL:COMPILE function (which is based on the same %COMPILE
+ mechanism) get confused by
+(defun sxhash (x)
+ (labels ((sxhash-number (x)
+ (etypecase x
+ (fixnum (sxhash x)) ; through DEFTRANSFORM
+ (integer (sb!bignum:sxhash-bignum x))
+ (single-float (sxhash x)) ; through DEFTRANSFORM
+ (double-float (sxhash x)) ; through DEFTRANSFORM
+ #!+long-float (long-float (error "stub: no LONG-FLOAT"))
+ (ratio (let ((result 127810327))
+ (declare (type fixnum result))
+ (mixf result (sxhash-number (numerator x)))
+ (mixf result (sxhash-number (denominator x)))
+ result))
+ (complex (let ((result 535698211))
+ (declare (type fixnum result))
+ (mixf result (sxhash-number (realpart x)))
+ (mixf result (sxhash-number (imagpart x)))
+ result))))
+ (sxhash-recurse (x &optional (depthoid +max-hash-depthoid+))
+ (declare (type index depthoid))
+ (typecase x
+ (list
+ (if (plusp depthoid)
+ (mix (sxhash-recurse (car x) (1- depthoid))
+ (sxhash-recurse (cdr x) (1- depthoid)))
+ 261835505))
+ (instance
+ (if (typep x 'structure-object)
+ (logxor 422371266
+ (sxhash ; through DEFTRANSFORM
+ (class-name (layout-class (%instance-layout x)))))
+ 309518995))
+ (symbol (sxhash x)) ; through DEFTRANSFORM
+ (number (sxhash-number x))
+ (array
+ (typecase x
+ (simple-string (sxhash x)) ; through DEFTRANSFORM
+ (string (%sxhash-substring x))
+ (bit-vector (let ((result 410823708))
+ (declare (type fixnum result))
+ (dotimes (i (min depthoid (length x)))
+ (mixf result (aref x i)))
+ result))
+ (t (logxor 191020317 (sxhash (array-rank x))))))
+ (character
+ (logxor 72185131
+ (sxhash (char-code x)))) ; through DEFTRANSFORM
+ (t 42))))
+ (sxhash-recurse x)))
+ complaining "function called with two arguments, but wants exactly
+ one" about SXHASH-RECURSE. (This might not be strictly a new bug,
+ since IIRC post-fork CMU CL has also had problems with &OPTIONAL
+ 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.)
+
+133:
+ Trying to compile something like
+ (sb!alien:def-alien-routine "breakpoint_remove" sb!c-call:void
+ (code-obj sb!c-call:unsigned-long)
+ (pc-offset sb!c-call:int)
+ (old-inst sb!c-call:unsigned-long))
+ in SBCL-0.pre7.86.flaky7.22 after warm init fails with an error
+ cannot use values types here
+ probably because the SB-C-CALL:VOID type gets translated to (VALUES).
+ It should be valid to use VOID for a function return type, so perhaps
+ instead of calling SPECIFIER-TYPE (which excludes all VALUES types
+ automatically) we should call VALUES-SPECIFIER-TYPE and handle VALUES
+ types manually, allowing the special case (VALUES) but still excluding
+ all more-complex VALUES types.
+
+135:
+ Ideally, uninterning a symbol would allow it, and its associated
+ FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However,
+ at least as of sbcl-0.7.0, this isn't the case. Information about
+ FDEFINITIONs and PROCLAIMed properties is stored in globaldb.lisp
+ essentially in ordinary (non-weak) hash tables keyed by symbols.
+ Thus, once a system has an entry in this system, it tends to live
+ forever, even when it is uninterned and all other references to it
+ are lost.
+
+136:
+ (reported by Arnaud Rouanet on cmucl-imp 2001-12-18)
+ (defmethod foo ((x integer))
+ x)
+ (defmethod foo :around ((x integer))
+ (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".
+
+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/*.*").
+
projects / sbcl.git / blobdiff