bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#40693: 28.0.50; json-encode-alist changes alist


From: João Távora
Subject: bug#40693: 28.0.50; json-encode-alist changes alist
Date: Fri, 22 May 2020 21:14:20 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux)

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

>> Am I missing something or doesn't this work like you want?
>
> There's a problem with the conditional require at byte-compile time.  If
> the version of Emacs doing the byte-compilation has native JSON support,
> then it will generate invalid byte-code (and complain) for the case
> where there is no native JSON support.  In other words, there will be a
> bug when an Emacs without native JSON loads a file that was
> byte-compiled in an Emacs with native JSON.

This doesn't give any any warning:

    (defvar foo-42 42)
     
    (provide 'foo)
    ;; foo.el ends here

and a bar.el

    (eval-and-compile
      (defvar bar-have-native-42 t) ;; or nil
     
      (unless bar-have-native-42 
        (require 'foo)))
     
    (defalias 'forty-two
      (if (eval-when-compile bar-have-native-42)
          (lambda () (message "%s" 42.0))
        (lambda () (message "%s" foo-42))))
    ;; bar.el ends here

And it seems to work in both cases:

     ~/tmp ❯❯❯ emacs -Q --batch -L . -f batch-byte-compile bar.el
     ~/tmp ❯❯❯ emacs -Q --batch -L . -l bar.elc -f forty-two
     42.0
     # now change that t to nil
     ~/tmp ❯❯❯ emacs -Q --batch -L . -f batch-byte-compile bar.el
     ~/tmp ❯❯❯ emacs -Q --batch -L . -l bar.elc -f forty-two
     42

But indeed in the recipe I gave you, I had forgotten the second
eval-when-compile.  If you take that away, it warns again.

No idea how to check if byte-code is "valid" or not: I just check the
warnings.  Can you tell me?

> Thanks.  I've therefore gone with the original patch[1], as it exhibits
> correct behaviour and is the least intrusive, but you should obviously
> feel free to tweak it as you prefer.

I think I'll let it be, the reason I'm not a huge fan is the foward
declarations of individual functions and variables, but it's not so bad.

João





reply via email to

[Prev in Thread] Current Thread [Next in Thread]