Error for wrong number of args to structure accessor

[gz]

This gets a compile time error rather than a compiler warning:

Welcome to Clozure Common Lisp Version 1.9-dev-r15341 (DarwinX8664)!
? (defstruct foo bar)
FOO
? (defun test () (foo-bar))
> Error: Required arguments in (CCL::STRUCTURE-TYPECHECK FOO) don't match lambda list (CCL::STRUCT CCL::TYPESPEC).
> While executing: (:INTERNAL CCL::NX1-COMPILE-LAMBDA), in process listener(1).
> Type :GO to continue, :POP to abort, :R for a list of available restarts.
> If continued: continue compilation ignoring this form
> Type :? for other options.
1 > 

[gb]

There are lots of cases - including things like:

(defun foo () (cdr))

- where calls with the wrong number of args generate compile-time errors instead of warnings/run-time errors. Generating a warning and compiling a call to #'CDR might be preferable, but there's at least some argument for the current behavior ("the definition is so confused that it's calling CDR with the wrong number of args; compiling it and letting you execute the result likely won't end well ...")

If we generated a compile-time error for the call to FOO-BAR (and complained that a required argument to FOO-BAR was missing), that'd seem to me to be not very different from the (CDR) case, and if it's reasonable to generate a compile-time error for (CDR) it seems to me to be as reasonable to do so for (FOO-BAR). What seems to be most unreasonable about your example is that we've already sailed past checking the number of args in the call to FOO-BAR and blow up somewhere out in compiler transform land with an error involving some internal function/macro.

[gz]

Yes, the main issue is that it's hard to figure out where (in your source) you made the error, you have to sort of dig through the guts of the compiler on the stack to even find which accessor you're calling. I would certainly prefer a warning to an error but I agree that's separate issue.

[gb]

(In [15349]) In NX-TRANSFORM, don't transform structure accessors that're called with other than 1 arg. In SETF, error at macroexpand time if a structure accessor is called with other than 1 arg. (There's not a lot else to do here.) Fixes ticket:961 in the trunk.

(IIRC, there's another open ticket which may describe the same problem but doesn't provide a reproducible test case.)