bug#71555: 29.3.50; Native-compilation sets some variable to nil unexpectedly.

[Andrea Corallo]

Sévère Durand <mmemmew@gmail.com> writes:

> Hello:
>
> I recently found that sometimes an argument of a function is
> unexpectedly set to nil when the function is natively compiled.
>
> A recipe to reproduce the behaviour is as follows.
>
> ```elisp
> (defun test (&optional start)
>   "Test the values of START."
>   (message "start is %S" start)
>   (cond
>    ((not (integer-or-marker-p start))
>     (message "entered first cond variant")
>     (setq start nil))
>    ((and
>      (markerp start)
>      (not (equal (marker-buffer start) (current-buffer))))
>     (message "entered second cond variant")
>     (setq start nil)))
>   (message "start is %S" start))
> (native-compile 'test)
> (test 12)
> ```
>
> When I evaluate the above forms in sequence, I got the following two
> messages:
>
> start is 12
> start is nil
>
> As can be seen from the above, no `cond` variants are triggered, so the
> variable START should have the value 12, while it becomes nil at the
> end.
>
> Sorry if this example is not minimal: I found this behaviour in my
> package, so copied the relevant parts here.  I am not sure what a 
> minimal example would be.
>
> Hope this report is helpful.

Hi Sévère,

I can't reproduce on master so the bug there is fixed.

AFAIK we don't plan to release a new 29 so I'm not sure it's worth the
effort of investigating and producing a backport for this bug.

Eli WDYT?

Thanks

  Andrea