X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;ds=sidebyside;f=BUGS;h=4e6b5db06e6c4e207254fdd32fd96af10bf8e66f;hb=3586bad78cd1b61c356ec74a4e7bcced1eb69cb3;hp=4dd6c3a886c600d3007fcdf57476ada9aca1fb67;hpb=b0fab8a8c774f4e2921877c408ecca0b39d38676;p=sbcl.git diff --git a/BUGS b/BUGS index 4dd6c3a..4e6b5db 100644 --- a/BUGS +++ b/BUGS @@ -1166,15 +1166,6 @@ WORKAROUND: would be to put the check between evaluation of arguments, but it could be tricky to check result types of PROG1, IF etc. -228: "function-lambda-expression problems" - in sbcl-0.7.9.6x, from the REPL: - * (progn (declaim (inline foo)) (defun foo (x) x)) - FOO - * (function-lambda-expression #'foo) - (SB-C:LAMBDA-WITH-LEXENV NIL NIL NIL (X) (BLOCK FOO X)), NIL, FOO - but this first return value is not suitable for input to FUNCTION or - COMPILE, as required by ANSI. - 229: (subtypep 'function '(function)) => nil, t. @@ -1201,9 +1192,6 @@ WORKAROUND: (+ x 2))) (foo 1d0 5) => segmentation violation -234: - (fixed in sbcl-0.7.10.36) - 235: "type system and inline expansion" a. (declaim (ftype (function (cons) number) acc)) @@ -1257,6 +1245,32 @@ 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. + +241: "DEFCLASS mysteriously remembers uninterned accessor names." + (from tonyms on #lisp IRC 2003-02-25) + In sbcl-0.7.12.55, typing + (defclass foo () ((bar :accessor foo-bar))) + (profile foo-bar) + (unintern 'foo-bar) + (defclass foo () ((bar :accessor foo-bar))) + gives the error message + "#:FOO-BAR already names an ordinary function or a macro." + So it's somehow checking the uninterned old accessor name instead + of the new requested accessor name, which seems broken to me (WHN). + DEFUNCT CATEGORIES OF BUGS IR1-#: These labels were used for bugs related to the old IR1 interpreter.