bug#66628: 30.0.50; EMACS_GENERATE_DYNVARS emits symbols with position

[Mattias Engdegård]

19 okt. 2023 kl. 08.32 skrev Basil L. Contovounesios <contovob@tcd.ie>:

> $ EMACS_GENERATE_DYNVARS=1 emacs -Q -batch -f batch-byte-compile foo.el
>  Generating /tmp/foo.elc.dynvars
> 
>  $ cat foo.elc.dynvars
>  (#<symbol foo-y at 62> . "/tmp/foo.el")
>  (#<symbol foo-x at 47> . "/tmp/foo.el")

Oops, good that you found this. The patch looks fine.
Thank you!

We could actually contemplate enriching the .dynvars format with source 
locations of the declarations when available, but it's perhaps just 
gold-plating at this point.

> Side question: if I replace
> 
>  (let ((foo-y 1))
>    (ignore foo-y)
>    (setq foo-y 2))
> 
> with
> 
>  (let ((foo-y 1))
>    (ignore foo-y)
>    (bar-x foo-y))
> 
> in bar.el (i.e. foo-y is only read, never set), the .dynvars warning
> about foo-y disappears.  I assume this is due to an earlier cconv /
> constant propagation pass, is that right?

Yes, constant propagation will substitute 1 for `foo-y` in the second case 
during Lisp-level optimisation because absent any dynamic declaration the 
variable is assumed to be lexical there. The warning is only emitted in the 
backend (codegen) which is admittedly a bit late.

>  If so, I'm curious
> whether/how the .dynvars feature could be adapted to cope, e.g. by
> taking place at an earlier stage.

Yes, it might be possible to move it to the frontend and in fact it's generally 
preferable to check for warnings at that stage. You could try doing that if you 
wish; I would like to make a frontend refactoring to make this sort of thing 
easier -- right now the frontend is part of cconv, except for the bit that's in 
macroexp-all.