X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=9e3167335d96dbc385a931e2afbb26b6c28c8157;hb=7e6637658236983ecbabea50f167fb9d3c5ed505;hp=a2c61e520f7575b0e59d74bbdf9bd69be6f706a1;hpb=334af30b26555f0bf706f7157b399bdbd4fad548;p=sbcl.git diff --git a/BUGS b/BUGS index a2c61e5..9e31673 100644 --- a/BUGS +++ b/BUGS @@ -118,33 +118,6 @@ WORKAROUND: (during macroexpansion of IN-PACKAGE, during macroexpansion of DEFFOO) -14: - The ANSI syntax for non-STANDARD method combination types in CLOS is - (DEFGENERIC FOO (X) (:METHOD-COMBINATION PROGN)) - (DEFMETHOD FOO PROGN ((X BAR)) (PRINT 'NUMBER)) - If you mess this up, omitting the PROGN qualifier in in DEFMETHOD, - (DEFGENERIC FOO (X) (:METHOD-COMBINATION PROGN)) - (DEFMETHOD FOO ((X BAR)) (PRINT 'NUMBER)) - the error mesage is not easy to understand: - INVALID-METHOD-ERROR was called outside the dynamic scope - of a method combination function (inside the body of - DEFINE-METHOD-COMBINATION or a method on the generic - function COMPUTE-EFFECTIVE-METHOD). - It would be better if it were more informative, a la - The method combination type for this method (STANDARD) does - not match the method combination type for the generic function - (PROGN). - Also, after you make the mistake of omitting the PROGN qualifier - on a DEFMETHOD, doing a new DEFMETHOD with the correct qualifier - no longer works: - (DEFMETHOD FOO PROGN ((X BAR)) (PRINT 'NUMBER)) - gives - INVALID-METHOD-ERROR was called outside the dynamic scope - of a method combination function (inside the body of - DEFINE-METHOD-COMBINATION or a method on the generic - function COMPUTE-EFFECTIVE-METHOD). - This is not very helpful.. - 15: (SUBTYPEP '(FUNCTION (T BOOLEAN) NIL) '(FUNCTION (FIXNUM FIXNUM) NIL)) => T, T @@ -225,10 +198,12 @@ WORKAROUND: 26: reported by Sam Steingold on the cmucl-imp mailing list 12 May 2000: - -Also, there is another bug: `array-displacement' should return an array -or nil as first value (as per ANSI CL), while CMUCL declares it as -returning an array as first value always. + Also, there is another bug: `array-displacement' should return an + array or nil as first value (as per ANSI CL), while CMUCL declares + it as returning an array as first value always. + (Actually, I think the old CMU CL version in SBCL never returns NIL, + i.e. it's not just a declaration problem, but the definition doesn't + behave ANSIly.) 27: Sometimes (SB-EXT:QUIT) fails with @@ -530,6 +505,16 @@ Error in function C::GET-LAMBDA-TO-COMPILE: or query the current working directory (a la Unix "chdir" and "pwd"), which is functionality that ILISP needs (and currently gets with low-level hacks). + When this is fixed, probably the more-or-less-parallel Unix-level + hacks + DEFAULT-DIRECTORY + %SET-DEFAULT-DIRECTORY + etc.? + should go away. Also we need to figure out what's the proper way to + deal with the interaction of users assigning new values to + *DEFAULT-PATHNAME-DEFAULTS* and cores being saved and restored. + (Perhaps just make restoring from a save always overwrite the old + value with the new Unix-level default directory?) 60: The debugger LIST-LOCATIONS command doesn't work properly. @@ -811,13 +796,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: (I haven't tried to investigate this bug enough to guess whether there might be any user-level symptoms.) -87: - Despite what the manual says, (DECLAIM (SPEED 0)) doesn't cause - things to be byte compiled. This seems to be true in cmucl-2.4.19, - too: (COMPILE-FILE .. :BYTE-COMPILE T) causes byte-compilation, - but ordinary COMPILE-FILE of a file containing (DECLAIM (SPEED 0)) - does not. - 90: a latent cross-compilation/bootstrapping bug: The cross-compilation host's CL:CHAR-CODE-LIMIT is used in target code in readtable.lisp @@ -838,13 +816,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: clear what's the best fix. (See the "bug in type handling" discussion on cmucl-imp ca. 2001-03-22 and ca. 2001-02-12.) -92: - (< SB-EXT:SINGLE-FLOAT-POSITIVE-INFINITY 100) signals an error: - error in function SB-KERNEL:INTEGER-DECODE-SINGLE-FLOAT: - can't decode NaN or infinity: #.EXT:SINGLE-FLOAT-POSITIVE-INFINITY - This is a bug in the original CMU CL code. I reported it to cmucl-imp - 2001-03-22 in hopes that they'll fix it for us. - 93: In sbcl-0.6.11.26, (COMPILE 'IN-HOST-COMPILATION-MODE) in src/cold/shared.lisp doesn't correctly translate the @@ -864,6 +835,102 @@ Error in function C::GET-LAMBDA-TO-COMPILE: (:LINUX :X86 :IEEE-FLOATING-POINT :SB-CONSTRAIN-FLOAT-TYPE :SB-TEST :SB-INTERPRETER :SB-DOC :UNIX ...) is not of type SYMBOL. +94a: + Inconsistencies between derived and declared VALUES return types for + DEFUN aren't checked very well. E.g. the logic which successfully + catches problems like + (declaim (ftype (function (fixnum) float) foo)) + (defun foo (x) + (declare (type integer x)) + (values x)) ; wrong return type, detected, gives warning, good! + fails to catch + (declaim (ftype (function (t) (values t t)) bar)) + (defun bar (x) + (values x)) ; wrong number of return values, no warning, bad! + The cause of this is seems to be that (1) the internal function + VALUES-TYPES-EQUAL-OR-INTERSECT used to make the check handles its + arguments symmetrically, and (2) when the type checking code was + written back when when SBCL's code was still CMU CL, the intent + was that this case + (declaim (ftype (function (t) t) bar)) + (defun bar (x) + (values x x)) ; wrong number of return values; should give warning? + not be warned for, because a two-valued return value is considered + to be compatible with callers who expects a single value to be + returned. That intent is probably not appropriate for modern ANSI + Common Lisp, but fixing this might be complicated because of other + divergences between auld-style and new-style handling of + multiple-VALUES types. (Some issues related to this were discussed + on cmucl-imp at some length sometime in 2000.) + +95: + The facility for dumping a running Lisp image to disk gets confused + when run without the PURIFY option, and creates an unnecessarily large + core file (apparently representing memory usage up to the previous + high-water mark). Moreover, when the file is loaded, it confuses the + GC, so that thereafter memory usage can never be reduced below that + level. + +96: + The TRACE facility can't be used on some kinds of functions. + (Basically, the breakpoint facility was incompletely implemented + in the X86 port of CMU CL, and hasn't been fixed in SBCL.) + +98: + In sbcl-0.6.11.41 (and in all earlier SBCL, and in CMU + CL), out-of-line structure slot setters are horribly inefficient + whenever the type of the slot is declared, because out-of-line + structure slot setters are implemented as closures to save space, + so the compiler doesn't compile the type test into code, but + instead just saves the type in a lexical closure and interprets it + at runtime. + A proper solution involves deciding whether it's really worth + saving space by implementing structure slot accessors as closures. + (If it's not worth it, the problem vanishes automatically. If it + is worth it, there are hacks we could use to force type tests to + be compiled anyway, and even shared. E.g. we could implement + an EQUAL hash table mapping from types to compiled type tests, + and save the appropriate compiled type test as part of each lexical + closure; or we could make the lexical closures be placeholders + which overwrite their old definition as a lexical closure with + a new compiled definition the first time that they're called.) + As a workaround for the problem, #'(SETF FOO) expressions can + be replaced with (EFFICIENT-SETF-FUNCTION FOO), where +(defmacro efficient-setf-function (place-function-name) + (or #+sbcl (and (sb-impl::info :function :accessor-for place-function-name) + ;; a workaround for the problem, encouraging the + ;; inline expansion of the structure accessor, so + ;; that the compiler can optimize its type test + (let ((new-value (gensym "NEW-VALUE-")) + (structure-value (gensym "STRUCTURE-VALUE-"))) + `(lambda (,new-value ,structure-value) + (setf (,place-function-name ,structure-value) + ,new-value)))) + ;; no problem, can just use the ordinary expansion + `(function (setf ,place-function-name)))) + +99: + DESCRIBE interacts poorly with *PRINT-CIRCLE*, e.g. the output from + (let ((*print-circle* t)) (describe (make-hash-table))) + is weird, + # is an . (EQL) + Its SIZE is 16. + Its REHASH-SIZE is 1.5. Its REHASH-THRESHOLD is . (1.0) + It holds 0 key/value pairs. + where the ". (EQL)" and ". (1.0)" substrings are screwups. + (This is likely a pretty-printer problem which happens to + be exercised by DESCRIBE, not actually a DESCRIBE problem.) + +100: + There's apparently a bug in CEILING optimization which caused + Douglas Crosher to patch the CMU CL version. Martin Atzmueller + applied the patches to SBCL and they didn't seem to cause problems + (as reported sbcl-devel 2001-05-04). However, since the patches + modify nontrivial code which was apparently written incorrectly + the first time around, until regression tests are written I'm not + comfortable merging the patches in the CVS version of SBCL. + + KNOWN BUGS RELATED TO THE IR1 INTERPRETER (Note: At some point, the pure interpreter (actually a semi-pure