bugfix: do not expand defun body with name in scope.

This is a revert of November 2016 commit
c924c9ed603bfda6d52d2fca099d42ff2cb02e2c.

The commit claims that it fixes a bug, but in fact it
introduces one. There is no discussion in that commit about
what motivated it.

The commit which follows that one introduces a
naivey-implemented diagnostic for catching unbound functions
at macro-expansion time, so the likely motivation for this
wrong fix was to suppress false positives from that naive
diagnostic for recursive functions. That has long since been
replaced by a better approach.

Because of the bug, we cannot do this very useful thing: we
cannot write an inline version of a funtion as a macro first,
and then a real function which just calls that macro:

  (defmacro foo (arg) ...)

  (defun foo (arg) (foo arg))

The bug causes the (foo arg) call in this function not to be
expanded, due to the shadowing.

* eval.c (do_expand): When expanding defun, do not introduce
the function's name as a lexical function binding, because it
isn't one.

1 files changed, 1 insertions, 4 deletions

diff --git a/eval.c b/eval.c
index b9055404..bf0dc246 100644
--- a/eval.c
+++ b/eval.c
@@ -4808,10 +4808,7 @@ again:
         cons_bind (params_ex, body_ex0,
                    expand_params(params, body, menv,
                                  eq(sym, defmacro_s), form));
-        val inter_env = make_var_shadowing_env(menv, get_param_syms(params_ex));
-        val new_menv = if3(sym == defun_s,
-                           make_fun_shadowing_env(inter_env, cons(name, nil)),
-                           inter_env);
+        val new_menv = make_var_shadowing_env(menv, get_param_syms(params_ex));
         val body_ex = expand_progn(body_ex0, new_menv);
         val form_ex = form;