Re: [nongnu] elpa/racket-mode 363246ac70 1/2: Fix cl-loop byte-compiler warnings

[Greg Hendershott]

>>     Fix cl-loop byte-compiler warnings
>>
>>     Frustratingly, the work-around of introducing a dummy `let` binding
>>     for the cl-loop index variable works on older versions of Emacs... but
>>     on bleeding edge Emacs starting c. a week ago starts to cause a
>>     different warning unless the variable is used.
>
> I plead guilty.  Sorry 'bout that.

No worries. That's an expected cost of enabling warnings-as-errors,
combined with having CI that runs tests against the main branch.

> Note that your workaround for the workaround could receive a warning in
> the future (that code looks very odd and we were recently talking about
> adding warnings for such unusual codes where an expression whose return
> value is ignored consist in just a constant or a variable lookup).
>
> So you might like to pass your dummy references to `i` to `ignore`,
> which is the "standard" idiom to say "don't bother warning me if I don't
> use this variable" and which the compiler already treats specially.

Ah. I tend to forget about `ignore` as a signal, or at least confuse it
with an "ignore" from some other lisp where it's just an s-expression
comment form.

>>     So to make this work across all versions (so far) of Emacs, we need a
>>     work-around for the work-around.
>
> The upside is that you should be able to drop the workaround as soon as
> you don't need to support Emacs<30 any more :-)
>
> You can also use a silly macro
>
>     (defmacro my-workaround-for-cl-loop-bug65833 (var &rest body)
>       (if (>= emacs-major-version 30)
>           (macroexp-progn body)
>         `(let (,var) ,@body)))

Does that mean `cl-loop` will handle this itself in its expansion?
Because that was going to be my Captain Obvious suggestion. :)

p.s. Maybe there's even a way to address this for macros in general? I
don't know Emacs Lisp expansion internals, but could macroexpand add
whatever remediation(s) like `ignore` that may be required -- and that's
one place to adjust as the optimizer or warnings are fine-tuned from
time to time? The theory being that such warnings are N/A and
non-actionable to _users_ of a macro. Just maybe the author. But...
maybe I'm over-thinking and/or misunderstanding the problem here.