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?