bug#45056: 28.0.50; lexical-let doesn't work with returned closures on nativecomp

[Mark A. Hershberger]

Andrea Corallo <akrl@sdf.org> writes:

> "Mark A. Hershberger" <mah@nichework.com> writes:
>
>> On Dec 5, 2020, at 5:06 PM, Andrea Corallo akrl@sdf.org wrote:
>>> could you provide a reproducer I can load and run possibly with -batch?
>>
>> I'm not sure how to do that since the file executed with -batch would be 
>> eval'd at runtime and this is using compiled code.
>
> this is not a problem, from batch one can always run
>
> (load (native-compile ".../test.el"))
> (test-entry-point)
>
> What we are interested in here is "test.el".

Here is test.el:

--- start test.el ---
(eval-when-compile
  (require 'cl))

(defun test-lambda (msg)
  "A test lambda that doesn't get the MSG."
  (lexical-let ((msg msg))
    (lambda (proc event-type)
      (message (concat "this is the message: " msg)))))

(defun test-entry-point ()
  "Demonstrate the problem."
  (message "before")
  (make-process
   :name "demo"
   :command (list "/bin/true")
   :sentinel (test-lambda "boom"))
  (sleep-for 0 500))
--- end test.el ---

Here is the output I get from emacs' master branch vs the native-comp
branch:

--- without native-compile ---
$ emacs --batch --eval '(progn (load "/home/mah/test.el") (test-entry-point))'
Loading /home/mah/test.el (source)...
Package cl is deprecated
before
this is the message: boom
--- end without native-compile ---

--- with native-compile ---
$ emacs --batch --eval '(progn (load (native-compile "/home/mah/test.el")) 
(test-entry-point))'

In toplevel form:
test.el:2:13: Warning: Package cl is deprecated
Loading 
/home/mah/.emacs.d/eln-cache/28.0.50-x86_64-pc-linux-gnu-0614bf52f1a04effb8fa710bbd17ffb5/test-82cb1d36939659f32d2428302ae393bd-703fa204fc5f510a11ffb237d3150bfe.eln
 (native compiled elisp)...
before
--- end with native-compile ---

Note that this shows a difference, but not necessarily the one I was
after originally. I was expecting a complaint about 'msg' not being
defined.

Running this interactively behaves differently (I get "this is the
message: boom"), so I think this shows a different bug than the one I
originally described.