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
(Also, when this is fixed, we can enable the code in PROCLAIM which
checks for incompatible FTYPE redeclarations.)
-18:
- from DTC on the CMU CL mailing list 25 Feb 2000:
-;;; Compiler fails when this file is compiled.
-;;;
-;;; Problem shows up in delete-block within ir1util.lisp. The assertion
-;;; (assert (member (functional-kind lambda) '(:let :mv-let :assignment)))
-;;; fails within bind node branch.
-;;;
-;;; Note that if c::*check-consistency* is enabled then an un-reached
-;;; entry is also reported.
-;;;
-(defun foo (val)
- (declare (values nil))
- nil)
-(defun bug (val)
- (multiple-value-call
- #'(lambda (res)
- (block nil
- (tagbody
- loop
- (when res
- (return nil))
- (go loop))))
- (foo val))
- (catch 'ccc1
- (throw 'ccc1
- (block bbbb
- (tagbody
-
- (let ((ttt #'(lambda () (go cccc))))
- (declare (special ttt))
- (return-from bbbb nil))
-
- cccc
- (return-from bbbb nil))))))
-
19:
(I *think* this is a bug. It certainly seems like strange behavior. But
- the ANSI spec is scary, dark, and deep..)
+ the ANSI spec is scary, dark, and deep.. -- WHN)
(FORMAT NIL "~,1G" 1.4) => "1. "
(FORMAT NIL "~3,1G" 1.4) => "1. "
Process inferior-lisp exited abnormally with code 1
I haven't noticed a repeatable case of this yet.
-29:
- some sort of bug in inlining and RETURN-FROM in sbcl-0.6.5: Compiling
- (DEFUN BAR? (X)
- (OR (NAR? X)
- (BLOCK USED-BY-SOME-Y?
- (FLET ((FROB (STK)
- (DOLIST (Y STK)
- (UNLESS (REJECTED? Y)
- (RETURN-FROM USED-BY-SOME-Y? T)))))
- (DECLARE (INLINE FROB))
- (FROB (RSTK X))
- (FROB (MRSTK X)))
- NIL)))
- gives
- error in function SB-KERNEL:ASSERT-ERROR:
- The assertion (EQ (SB-C::CONTINUATION-KIND SB-C::CONT) :BLOCK-START) failed.
- This is still present in sbcl-0.6.8.
-
31:
In some cases the compiler believes type declarations on array
elements without checking them, e.g.
(Also, verify that the compiler handles declared function
return types as assertions.)
-38:
- DEFMETHOD doesn't check the syntax of &REST argument lists properly,
- accepting &REST even when it's not followed by an argument name:
- (DEFMETHOD FOO ((X T) &REST) NIL)
-
41:
TYPEP of VALUES types is sometimes implemented very inefficiently, e.g. in
(DEFTYPE INDEXOID () '(INTEGER 0 1000))
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,
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
-
-138:
- a cross-compiler bug in sbcl-0.pre7.107
-
- $ cat > /tmp/bug139.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/bug139.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.
-
-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/*.*").
+ 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
KNOWN BUGS RELATED TO THE IR1 INTERPRETER
projects / sbcl.git / blobdiff