Custom Query (1030 matches)
Results (445 - 447 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #288 | fixed | Confusing error message for misplaced DECLARE | ||
| Description |
Compiling a file with this contents: (prog1
(declare (ignore foo)))
yields a confusing error message Welcome to Clozure Common Lisp Version 1.2-r9226-RC1 (LinuxX8664)! ? (compile-file "foo.lisp") ;Compiler warnings for "/home/hans/profiler/foo.lisp" : ; In an anonymous lambda form: DECLARE not expected in (DECLARE (IGNORE FOO)) > Error: No MAKE-LOAD-FORM method is defined for #<CCL::SIMPLE-PROGRAM-ERROR #x 00040CFAF3D> The "DECLARE not expected" is clear, but the MAKE-LOAD-FORM thing is really confusing. It seems as if the compiler continues when it can't. |
|||
| #289 | fixed | DEFCLASS option processing | ||
| Description |
This was reported by Didier Verna on openmcl-devel a few times in the last week or so. Compiling a file that contains (defclass test-class (standard-class) ()) (defclass test () () (:metaclass test-class)) now errs at compile-time, apparently while doing a FIND-CLASS of TEST-CLASS while building the (new) class-keyvect. |
|||
| #290 | fixed | THE typechecking and evaluation order | ||
| Description |
This should already be fixed in r9331, but for the record and in case it rears its ugly head again. The TYPED-FORM acode operation (basically, the acode representation of THE) now takes an extra argument indicating whether or not a runtime typecheck should occur; this is set to T by the frontend at high SAFETY levels. Historically, a TYPED-FORM acode operation was considered "simple and side-effect free" if its operand was and could therefore be evaluated out-of-order, but this is no longer true if typehecking is involved. (Since that typechecking can involve function calls and a lot of register shuffling, a typechecking TYPED-FORM should be viewed as something that has unknown side-effects and which can at least change register contents.) |
|||
