bugfix: broken expansion of sys:lisp1-setq places.

This bug shows up as a spurious warning and incorrect
expansion from a from like (do set [@1 x] y).

In this situation, sys:lisp1-setq is involved in the
assignment to the place denoted by @1, because of the way the
do operator expands the (set [@1 x] y) expression. The @1
meta-variable is replaced by a gensym, but some intermediate
expansion takes place in an environment which has no binding
for the gensym, causing the place to be treated as if it were
a global variable, using sys:lisp1-setq. The subsequent real
expansion in the environment in which the gensym is now bound
then calls upon the expansion of sys:lisp1-setq, which
proceeds via the expand_lisp1_setq function. But now the
variable has a lexical binding.

This bug doesn't show up in ordinary expressions like
(set [foo x] y) which is why it went undetected for a year.

* eval.c (expand_lisp1_setq): Fix the missing symbol in
the generated code for the case when the symbol has a lexical
variable binding. We must emit (sys:setq <sym> <value>), not
(sys:setq <new-value>).

1 files changed, 1 insertions, 1 deletions

diff --git a/eval.c b/eval.c
index eb568b2e..64cfc1ad 100644
--- a/eval.c
+++ b/eval.c
@@ -2237,7 +2237,7 @@ static val expand_lisp1_setq(val form, val menv)
     }
 
     if (binding_type == var_k)
-      return expand(rlcp(cons(setq_s, cddr(form)), form), menv);
+      return expand(rlcp(cons(setq_s, cons(sym, cddr(form))), form), menv);
 
     if (binding_type == fun_k)
       eval_error(form, lit("~s: cannot assign lexical function ~s"), op, sym, nao);