2009/7/28 Peter Tsenter <ptsenter@hotmail.com>:
Question: how do you explain why the patch does not catch reinitialize-instance.error.1? How does this case differ from the other 3?
This seems to be related to eval. The make-instance form in reinitialize-instance.error.1 fails correctly when run directly, but when it's done inside eval, it doesn't fail. Investigations continue.. Btw, I do think that the initarg-check is going to the right direction, because I was able to fix CHANGE-CLASS.ERROR.4 by merely adding a symbolp test to valid-methodarg-p. I also have a fix for SHARED-INITIALIZE.ERROR.4, which doesn't cause regressions in other tests. That fix is a bit odd, because it requires that initform of (nil foo) is accepted, but something like ('(abc) foo) is not. The thing is, I have to test for (and initarg (not (symbolp initarg))) in std-shared-initialize, which checks that an initarg name must be a symbol (so things like :foo and :bar work) but it can also be nil. The nil case is quite curious. If it's not handled, CLASS-14.1 will fail. That test is (deftest class-14.1 (let ((c (make-instance 'class-14 nil 'x))) (s1 c)) x) That seems to be because there's an :initarg nil in the defclass. The class is (defclass class-14 () ((s1 :initarg nil :reader s1))) Any comments?