bug#67116: closed (byte-compile-let: reversing the order of evaluation of the clauses CAN make a difference.)

[GNU bug Tracking System]

Your message dated Mon, 13 Nov 2023 12:19:27 +0100
with message-id <C48106DC-0EF3-41F5-AD69-84BA30A0C19D@gmail.com>
and subject line Re: bug#67116: byte-compile-let: reversing the order of 
evaluation of the clauses CAN make a difference
has caused the debbugs.gnu.org bug report #67116,
regarding byte-compile-let: reversing the order of evaluation of the clauses 
CAN make a difference.
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
67116: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67116
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> byte-compile-let: reversing the order of evaluation of the clauses CAN make a difference.
>
>
>
>
> Date: 
>
> Sat, 11 Nov 2023 22:48:43 +0000
>
>
>
>
> Hello, Emacs.
>
> Emacs master branch.
>
> In lisp/emacs-lisp/bytecomp.el (byte-compile-let), when the following
> form (from jit-lock--debug-fontify):
>
>                           (let
>                               ((beg pos)
>                                 (end (setq pos
>                                                (next-single-property-change
>                                                 pos 'fontified
>                                                 nil (point-max)))))
>                             (put-text-property beg end 'fontified nil)
>                             (jit-lock-fontify-now beg end))
>
> gets byte compiled, the order of evaluating BEG and END gets reversed so
> that END gets evaluated first.  Since the value for END contains (setq
> pos ...), BEG gets this updated value of POS rather then the original
> intended value.
>
> This particular bug in jit-lock.el can be fixed by using let* rather
> than let, but this isn't the point.  I believe (without testing) that
> the interpreted code for the form would evaluate BEG before END, hence
> testing it interpreted (e.g. under edebug) will give a false sense of
> correctness.
>
> The comment in byte-compile-let:
>
>       ;; Bind the variables.
>       ;; For `let', do it in reverse order, because it makes no
>       ;; semantic difference, but it is a lot more efficient since the
>       ;; values are now in reverse order on the stack.
>
> , is not true.  It can make a semantic difference.  So doing the binding
> in reverse order is a bug.
>
> -- 
> Alan Mackenzie (Nuremberg, Germany).
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#67116: byte-compile-let: reversing the order of evaluation of the clauses CAN make a difference
>
>
>
>
> Date: 
>
> Mon, 13 Nov 2023 12:19:27 +0100
>
>
>
>
> > There's a bug here, will fix.
>
> Now fixed on master. I'm very pleased that you reported this bug.
> (Of course it didn't have anything to do with order of evaluation at all but 
> you already understood that.)
>
> I didn't do a deep analysis of what code was affected by the bug but measuring 
> changes in the bytecode size, which is usually quite good, only two places 
> turned up: jit-lock--debug-fontify, which you already noticed, and
> c-forward-sws in cc-engine.el, where the code
>
>               (c-put-in-sws rung-pos
>                             (setq rung-pos (point)
>                                   last-put-in-sws-pos rung-pos)))
>
> was probably affected here. (Obviously the bug was out to get you personally, 
> Alan.)
>
>
>
> --- End Message ---