bug#64232: 28.2; Incorrect(?) byte compilation warning about ‘ansi-color-apply-on-region’

bug#64232: 28.2; Incorrect(?) byte compilation warning about ‘ansi-color-apply-on-region’

[Zack Weinberg]

With Emacs 28.2, this test .el file

```
;; -*- lexical-binding: t; coding: utf-8 -*-

(declare-function ansi-color-apply-on-region "ansi-color"
                  (begin end &optional preserve-sequences))
(autoload 'ansi-color-apply-on-region "ansi-color")

(eval-when-compile
  (check-declare-file byte-compile-current-file))

(defun zw-colorize-compilation-buffer ()
  "Interpret ANSI color escapes in a compilation-mode buffer, which
gets them out of the way of the error detector.  Intended for use via
compilation-filter-hook."
  (interactive)
  (let ((inhibit-read-only t))
    (ansi-color-apply-on-region (point-min) (point-max))))
```

provokes a byte compilation warning:

```
$ emacs -Q --batch -f batch-byte-compile test.el
uncompressing ansi-color.el.gz...
uncompressing ansi-color.el.gz...done

In end of data:
test.el:16:6: Warning: the function ‘ansi-color-apply-on-region’ might not be
    defined at runtime.
```

The combination of `declare-function` and `autoload` is intended to
ensure both that the byte compiler understands what’s going on, and
that `ansi-color-apply-on-region` really is guaranteed to be available
at runtime.  Also, I triple-checked that ansi-color.el really does
define this function.  Why is the compiler still complaining?

Analogous constructs work as expected for other functions that might
not yet be loaded when their caller is evaluated, e.g. this very
similar test file

```
;; -*- lexical-binding: t; coding: utf-8 -*-

(declare-function dired-get-marked-files "dired"
                  (&optional localp arg filter distinguish-one-marked error))
(autoload 'dired-get-marked-files "dired")

(eval-when-compile
  (check-declare-file byte-compile-current-file))

(defun zw-dired-find-marked-files (&optional arg)
  "Open each of the marked files, or the file under the point, or
with prefix arg, the next N files."
  (interactive "P")
  (mapc 'find-file (dired-get-marked-files nil arg)))
```

byte compiles without complaint.

zw

---
In GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.37, cairo version 1.16.0)
Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
System Description: Debian GNU/Linux 12 (bookworm)

Configured using:
 'configure
 CONFIG_SHELL=/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/bash
 SHELL=/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/bash
 --prefix=/gnu/store/gvbp7lp6yl3gsmz89kwajds2mh5179r5-emacs-28.2
 --enable-fast-install --with-modules --with-cairo
 --with-native-compilation --disable-build-details'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF
TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB

Important settings:
  value of $EMACSLOADPATH: /home/zack/.guix-profile/share/emacs/site-lisp:/gnu/store/gvbp7lp6yl3gsmz89kwajds2mh5179r5-emacs-28.2/share/emacs/28.2/lisp
  value of $LC_COLLATE: C
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  envrc-global-mode: t
  envrc-mode: t
  doom-modeline-mode: t
  selectrum-prescient-mode: t
  prescient-persist-mode: t
  editorconfig-mode: t
  override-global-mode: t
  typo-global-mode: t
  global-whitespace-mode: t
  global-auto-revert-mode: t
  selectrum-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
/home/zack/.config/emacs/elpa/transient-20230602.2121/transient hides /gnu/store/gvbp7lp6yl3gsmz89kwajds2mh5179r5-emacs-28.2/share/emacs/28.2/lisp/transient
/home/zack/.config/emacs/elpa/jsonrpc-1.0.17/jsonrpc hides /gnu/store/gvbp7lp6yl3gsmz89kwajds2mh5179r5-emacs-28.2/share/emacs/28.2/lisp/jsonrpc
/home/zack/.config/emacs/elpa/xref-1.6.3/xref hides /gnu/store/gvbp7lp6yl3gsmz89kwajds2mh5179r5-emacs-28.2/share/emacs/28.2/lisp/progmodes/xref
/home/zack/.config/emacs/elpa/project-0.9.8/project hides /gnu/store/gvbp7lp6yl3gsmz89kwajds2mh5179r5-emacs-28.2/share/emacs/28.2/lisp/progmodes/project
/home/zack/.config/emacs/elpa/flim-20230205.1423/sasl hides /gnu/store/gvbp7lp6yl3gsmz89kwajds2mh5179r5-emacs-28.2/share/emacs/28.2/lisp/net/sasl
/home/zack/.config/emacs/elpa/eldoc-1.14.0/eldoc hides /gnu/store/gvbp7lp6yl3gsmz89kwajds2mh5179r5-emacs-28.2/share/emacs/28.2/lisp/emacs-lisp/eldoc

Features:
(shadow flyspell ispell modb-legacy modb-standard elmo-passwd gnutls
network-stream nsm utf-7 elmo-imap4 time-stamp zw-wl-customization
wl-fldmgr wl-template wl-demo wl-thread wl-action wl wl-draft
wl-folder elmo-nntp elmo-filter wl-summary wl-refile wl-message
wl-mime mime-play filename wl-e21 wl-highlight elmo-mime mmelmo-buffer
mmelmo-imap mmimap mmbuffer mmgeneric wl-address wl-util pp wl-vars
wl-version elmo-net elmo-cache elmo-map elmo-dop modb-generic
elmo-flag elmo-localdir elmo elmo-signal elmo-msgdb modb modb-entity
elmo-date elmo-util elmo-vars elmo-version mime-edit mime-image
mime-view mime-conf calist invisible inv-23 mime-setup mail-mime-setup
semi-setup advice semi-def mime-parse mime luna eword-encode
eword-decode mel path-util pces pces-e20 pces-20 mime-def alist
mcs-e20 mcs-20 wid-edit mcharset std11 pccl pccl-20 broken static
apel-ver product timezone emacsbug message rmc puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
gnus-util rmail rmail-loaddefs time-date mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils face-remap pulse
envrc inheritenv ansi-color server all-the-icons all-the-icons-faces
data-material data-weathericons data-octicons data-fileicons
data-faicons data-alltheicons doom-modeline doom-modeline-segments
doom-modeline-env doom-modeline-core shrink-path f f-shortdoc shortdoc
text-property-search s dash nerd-icons nerd-icons-faces
nerd-icons-data nerd-icons-data-mdicon nerd-icons-data-flicon
nerd-icons-data-codicon nerd-icons-data-devicon
nerd-icons-data-sucicon nerd-icons-data-wicon nerd-icons-data-faicon
nerd-icons-data-powerline nerd-icons-data-octicon
nerd-icons-data-pomicon nerd-icons-data-ipsicon compat compat-29
edmacro kmacro selectrum-prescient selectrum minibuf-eldef crm
prescient char-fold comp comp-cstr warnings editorconfig
editorconfig-core editorconfig-core-handle editorconfig-fnmatch pcase
solarized-light-theme solarized-palettes solarized solarized-faces
color zw-functions use-package use-package-ensure use-package-delight
use-package-diminish use-package-bind-key bind-key easy-mmode
use-package-core package browse-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core
cl-macs eieio-loaddefs password-cache json subr-x map url-vars
cl-extra help-mode typo whitespace autorevert filenotify cl-loaddefs
cl-lib cus-load guix-emacs seq byte-opt gv bytecomp byte-compile cconv
info rx iso-transl tooltip eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode
register page tab-bar menu-bar rfn-eshadow isearch easymenu timer
select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese
eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese composite emoji-zwj charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 326012 10065)
 (symbols 48 22124 7)
 (strings 32 100305 5994)
 (string-bytes 1 2514246)
 (vectors 16 38478)
 (vector-slots 8 876336 24689)
 (floats 8 741 311)
 (intervals 56 365 0)
 (buffers 992 10))

bug#64232: 28.2; Incorrect(?) byte compilation warning about ‘ansi-color-apply-on-region’

[Eli Zaretskii]

> Date: Thu, 22 Jun 2023 15:56:18 -0400
> From: Zack Weinberg <zack@owlfolio.org>
> 
> 
> With Emacs 28.2, this test .el file
> 
> ```
> ;; -*- lexical-binding: t; coding: utf-8 -*-
> 
> (declare-function ansi-color-apply-on-region "ansi-color"
>                   (begin end &optional preserve-sequences))
> (autoload 'ansi-color-apply-on-region "ansi-color")
> 
> (eval-when-compile
>   (check-declare-file byte-compile-current-file))
> 
> (defun zw-colorize-compilation-buffer ()
>   "Interpret ANSI color escapes in a compilation-mode buffer, which
> gets them out of the way of the error detector.  Intended for use via
> compilation-filter-hook."
>   (interactive)
>   (let ((inhibit-read-only t))
>     (ansi-color-apply-on-region (point-min) (point-max))))
> ```
> 
> provokes a byte compilation warning:
> 
> ```
> $ emacs -Q --batch -f batch-byte-compile test.el
> uncompressing ansi-color.el.gz...
> uncompressing ansi-color.el.gz...done
> 
> In end of data:
> test.el:16:6: Warning: the function ‘ansi-color-apply-on-region’ might not be
>     defined at runtime.
> ```
> 
> The combination of `declare-function` and `autoload` is intended to
> ensure both that the byte compiler understands what’s going on, and
> that `ansi-color-apply-on-region` really is guaranteed to be available
> at runtime.  Also, I triple-checked that ansi-color.el really does
> define this function.  Why is the compiler still complaining?

The problem is this part:

  (eval-when-compile
    (check-declare-file byte-compile-current-file))

Remove it, and the problem will go away.  So there's actually no
problem here with 'autoload' and 'declare-function'.

I don't understand why you are calling check-declare-file, and
moreover don't understand the argument you pass check-declare-file.
check-declare-file is a command supposed to be used interactively to
verify the 'declare' calls are valid in a given file; it shows the
results, if any, as delayed-warnings.  Can you explain why you do this
in the eval-when-compile form?

bug#64232: 28.2; Incorrect(?) byte compilation warning about ‘ansi-color-apply-on-region’

[Zack Weinberg]

On Sat, Jun 24, 2023, at 7:49 AM, Eli Zaretskii wrote:
>> Date: Thu, 22 Jun 2023 15:56:18 -0400 From: Zack Weinberg
>> <zack@owlfolio.org> The combination of `declare-function` and
>> `autoload` is intended to ensure both that the byte compiler
>> understands what’s going on, and that `ansi-color-apply-on-region`
>> really is guaranteed to be available at runtime.  Also, I triple-
>> checked that ansi-color.el really does define this function.  Why is
>> the compiler still complaining?
>
> The problem is this part:
>
>   (eval-when-compile
>     (check-declare-file byte-compile-current-file))
>
> I don't understand why you are calling check-declare-file, and
> moreover don't understand the argument you pass check-declare-file.
> check-declare-file is a command supposed to be used interactively to
> verify the 'declare' calls are valid in a given file; it shows the
> results, if any, as delayed-warnings.  Can you explain why you do this
> in the eval-when-compile form?

Because I want the declarations to be checked every time this file is
byte compiled??

Maybe it makes more sense if I say it like this: I've written manual
autoload forms for a bunch of functions that I *expect* to be defined in
various libraries.  If the guts of Emacs change and some of these
functions are now defined somewhere else, I want to be notified
immediately when I regenerate the .elc files for the new Emacs, not
later when I try to use the commands that depend on those autoloads.

Pairing each autoload with a declare-function form would achieve that
... if the byte compiler could be bothered to validate the declare-
function forms.  It doesn't, but check-declare does. So I kludge an
invocation of check-declare into the compilation.

> Remove it, and the problem will go away.  So there's actually no
> problem here with 'autoload' and 'declare-function'.

No, there is still a problem.  Let me restate the actual bug I was
trying to report, so you can see it more clearly.

Save the following file as test.el.

```
(declare-function ansi-color-apply-on-region "ansi-color"
                  (begin end &optional preserve-sequences))

(declare-function dired-get-marked-files "dired"
                  (&optional localp arg filter distinguish-one-marked error))

(eval-when-compile
  (check-declare-file byte-compile-current-file))

(defun colorize-buffer ()
  (interactive)
  (ansi-color-apply-on-region (point-min) (point-max)))

(defun find-marked-files ()
  (interactive)
  (mapc 'find-file (dired-get-marked-files)))
```

If you visit this file in emacs -Q and then invoke check-declare-file on
it interactively, check-declare-file generates no warnings, which is
correct.  However, if you invoke `emacs -Q --batch -f batch-byte-compile
test.el` from the shell, you will get this output:

```
uncompressing ansi-color.el.gz...
uncompressing ansi-color.el.gz...done
uncompressing dired.el.gz...
uncompressing dired.el.gz...done

In end of data:
test.el:13:4: Warning: the function ‘ansi-color-apply-on-region’ might not be
    defined at runtime.
```

"The function ‘...’ might not be defined" is the phrase used by
byte-compile-warn-about-unresolved-functions.  It's not a check-declare
diagnostic.

This *must* be some form of bug, because the behavior is inconsistent:
it complains about ansi-color-apply-on-region but not about dired-get-marked-files.

zw

bug#64232: 28.2; Incorrect(?) byte compilation warning about ‘ansi-color-apply-on-region’

[Michael Heerdegen]

[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]

"Zack Weinberg" <zack@owlfolio.org> writes:

> ```
> (declare-function ansi-color-apply-on-region "ansi-color"
>                   (begin end &optional preserve-sequences))
>
> (declare-function dired-get-marked-files "dired"
>                   (&optional localp arg filter distinguish-one-marked error))
>
> (eval-when-compile
>   (check-declare-file byte-compile-current-file))
>
> (defun colorize-buffer ()
>   (interactive)
>   (ansi-color-apply-on-region (point-min) (point-max)))
>
> (defun find-marked-files ()
>   (interactive)
>   (mapc 'find-file (dired-get-marked-files)))
> ```
>
> If you visit this file in emacs -Q and then invoke check-declare-file on
> it interactively, check-declare-file generates no warnings, which is
> correct.  However, if you invoke `emacs -Q --batch -f batch-byte-compile
> test.el` from the shell, you will get this output:
>
> ```
> uncompressing ansi-color.el.gz...
> uncompressing ansi-color.el.gz...done
> uncompressing dired.el.gz...
> uncompressing dired.el.gz...done
>
> In end of data:
> test.el:13:4: Warning: the function ‘ansi-color-apply-on-region’ might
> not be
>     defined at runtime.
> ```
>
> "The function ‘...’ might not be defined" is the phrase used by
> byte-compile-warn-about-unresolved-functions.  It's not a check-declare
> diagnostic.

Indeed - so we have an interference between byte compilation,
`eval-when-compile' and `check-declare-file'.  This seems to help and
might (?) be a good thing to do anyway:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-WIP-Try-to-fix-Bug-64232.patch --]
[-- Type: text/x-diff, Size: 1254 bytes --]

From e972af2cd4d27b42cad7cf697bcfa32127cb0591 Mon Sep 17 00:00:00 2001
From: Michael Heerdegen <michael_heerdegen@web.de>
Date: Wed, 28 Jun 2023 04:02:44 +0200
Subject: [PATCH] WIP: Try to fix Bug#64232

---
 lisp/emacs-lisp/bytecomp.el | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
index 99202185d8d..f468e34bb42 100644
--- a/lisp/emacs-lisp/bytecomp.el
+++ b/lisp/emacs-lisp/bytecomp.el
@@ -554,7 +554,9 @@ byte-compile-initial-macro-environment
                                  (let ((byte-compile-unresolved-functions
                                         byte-compile-unresolved-functions)
                                        (byte-compile-new-defuns
-                                        byte-compile-new-defuns))
+                                        byte-compile-new-defuns)
+                                       (byte-compile-noruntime-functions
+                                        byte-compile-noruntime-functions))
                                    (setf result
                                          (byte-compile-eval
                                           (byte-run-strip-symbol-positions
--
2.30.2


[-- Attachment #3: Type: text/plain, Size: 152 bytes --]


Would be nice if someone like Stefan or Mattias could tell whether this
is an appropriate addition (independently from this obscure issue).


Michael.

bug#64232: 28.2; Incorrect(?) byte compilation warning about ‘ansi-color-apply-on-region’

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
> index 99202185d8d..f468e34bb42 100644
> --- a/lisp/emacs-lisp/bytecomp.el
> +++ b/lisp/emacs-lisp/bytecomp.el
> @@ -554,7 +554,9 @@ byte-compile-initial-macro-environment
>                                   (let ((byte-compile-unresolved-functions
>                                          byte-compile-unresolved-functions)
>                                         (byte-compile-new-defuns
> -                                        byte-compile-new-defuns))
> +                                        byte-compile-new-defuns)
> +                                       (byte-compile-noruntime-functions
> +                                        byte-compile-noruntime-functions))
>                                     (setf result
>                                           (byte-compile-eval
>                                            (byte-run-strip-symbol-positions

Hmm... this doesn't look right: one of the main purpose of
`byte-compile-eval` is (beside calling `eval`) to populate
`byte-compile-noruntime-functions`, so if you let-bind it around the
call, it's like calling `eval` and we can just get rid of
`byte-compile-noruntime-functions` altogether.

The "natural" place to put the let-binding would be in
`byte-compile-close-variables` (assuming it still fixes the bug).


        Stefan

bug#64232: 28.2; Incorrect(?) byte compilation warning about ‘ansi-color-apply-on-region’

[Michael Heerdegen]

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

> > --- a/lisp/emacs-lisp/bytecomp.el
> > +++ b/lisp/emacs-lisp/bytecomp.el
> > @@ -554,7 +554,9 @@ byte-compile-initial-macro-environment
> >                                   (let ((byte-compile-unresolved-functions
> >                                          byte-compile-unresolved-functions)
> >                                         (byte-compile-new-defuns
> > -                                        byte-compile-new-defuns))
> > +                                        byte-compile-new-defuns)
> > +                                       (byte-compile-noruntime-functions
> > +                                        byte-compile-noruntime-functions))
> >                                     (setf result
> >                                           (byte-compile-eval
> >                                            (byte-run-strip-symbol-positions
>
> Hmm... this doesn't look right: one of the main purpose of
> `byte-compile-eval` is (beside calling `eval`) to populate
> `byte-compile-noruntime-functions`, so if you let-bind it around the
> call, it's like calling `eval` and we can just get rid of
> `byte-compile-noruntime-functions` altogether.

Hmm - ok.

> The "natural" place to put the let-binding would be in
> `byte-compile-close-variables` (assuming it still fixes the bug).

Seems it does not.  Maybe we should try to understand what is happening
first.

Part of the problem is the dependency

  check-declare -> compile -> comint -> ansi-color

so the compiler might think we are `requiring' ansi-color (which the
compiled file uses) inside our `eval-when-compile' by purpose.

The warning is the same as when one did just

#+begin_src emacs-lisp
(eval-when-compile
  (require 'ansi-color))
#+end_src

When removing that `eval-when-compile' the warning message goes away.
So the compiler warns stricter when something is required inside
`eval-when-compile', even if there would be no warning at all without
it.


Michael.

bug#64232: 28.2; Incorrect(?) byte compilation warning about ‘ansi-color-apply-on-region’

[Michael Heerdegen]

Zack Weinberg <zack@owlfolio.org> writes:

> (eval-when-compile
>   (check-declare-file byte-compile-current-file))

BTW, I think a better alternative might be

#+begin_src emacs-lisp
(require 'cl-lib)
(cl-eval-when (compile)
  (check-declare-file byte-compile-current-file))
#+end_src

which behaves like you want and also doesn't break loading the source of
your file like your version does.  If you don't want to load cl-lib, I
guess adding something like

#+begin_src emacs-lisp
(defmacro check-declarations ()
  (check-declare-file byte-compile-current-file)
  t)
(check-declarations)
#+end_src

could also work.

Michael.

bug#64232: 28.2; Incorrect(?) byte compilation warning about ‘ansi-color-apply-on-region’

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> The warning is the same as when one did just
>
> #+begin_src emacs-lisp
> (eval-when-compile
>   (require 'ansi-color))
> #+end_src
>
> When removing that `eval-when-compile' the warning message goes away.
> So the compiler warns stricter when something is required inside
> `eval-when-compile', even if there would be no warning at all without
> it.

Indeed, it's a vaguely known problem which we haven't tried to
fix seriously.

The usual workaround is to shuffle things around (e.g. move the

    (eval-when-compile
      (check-declare-file byte-compile-current-file))

earlier or later in the file) ... until the warnings disappear :-(

Someone™ should sit down and figure out how to make `bytecomp.el` keep
track of those things more reliably/predictably.
In the mean time, maybe we can simply tweak `byte-compile-eval` so it
never adds to `byte-compile-noruntime-functions` functions which have
already been seen/declared during the current compilation?


        Stefan


diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
index 99202185d8d..cfec4b3be06 100644
--- a/lisp/emacs-lisp/bytecomp.el
+++ b/lisp/emacs-lisp/bytecomp.el
@@ -1128,7 +1128,8 @@ byte-compile-eval
 		     ;; we arguably should add it to b-c-noruntime-functions,
                      ;; but it's not clear it's worth the trouble
 		     ;; trying to recognize that case.
-		     (unless (get f 'function-history)
+		     (unless (or (get f 'function-history)
+                                 (assq f byte-compile-function-environment))
                        (push f byte-compile-noruntime-functions)))))))))))))
 
 (defun byte-compile-eval-before-compile (form)

bug#64232: 28.2; Incorrect(?) byte compilation warning about ‘ansi-color-apply-on-region’

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Someone™ should sit down and figure out how to make `bytecomp.el` keep
> track of those things more reliably/predictably.
> In the mean time, maybe we can simply tweak `byte-compile-eval` so it
> never adds to `byte-compile-noruntime-functions` functions which have
> already been seen/declared during the current compilation?
>
>
> diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
> index 99202185d8d..cfec4b3be06 100644
> --- a/lisp/emacs-lisp/bytecomp.el
> +++ b/lisp/emacs-lisp/bytecomp.el
> @@ -1128,7 +1128,8 @@ byte-compile-eval
>  		     ;; we arguably should add it to b-c-noruntime-functions,
>                       ;; but it's not clear it's worth the trouble
>  		     ;; trying to recognize that case.
> -		     (unless (get f 'function-history)
> +		     (unless (or (get f 'function-history)
> +                                 (assq f byte-compile-function-environment))
>                         (push f byte-compile-noruntime-functions)))))))))))))

Seems appropriate (and fixes this bug).

Actually with that patch the situation looks already quite ok'ish to me.

Thx,

Michael.

bug#64232: 28.2; Incorrect(?) byte compilation warning about ‘ansi-color-apply-on-region’

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 64232@debbugs.gnu.org,  eliz@gnu.org,  zack@owlfolio.org
> Date: Fri, 30 Jun 2023 06:02:36 +0200
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > Someone™ should sit down and figure out how to make `bytecomp.el` keep
> > track of those things more reliably/predictably.
> > In the mean time, maybe we can simply tweak `byte-compile-eval` so it
> > never adds to `byte-compile-noruntime-functions` functions which have
> > already been seen/declared during the current compilation?
> >
> >
> > diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
> > index 99202185d8d..cfec4b3be06 100644
> > --- a/lisp/emacs-lisp/bytecomp.el
> > +++ b/lisp/emacs-lisp/bytecomp.el
> > @@ -1128,7 +1128,8 @@ byte-compile-eval
> >  		     ;; we arguably should add it to b-c-noruntime-functions,
> >                       ;; but it's not clear it's worth the trouble
> >  		     ;; trying to recognize that case.
> > -		     (unless (get f 'function-history)
> > +		     (unless (or (get f 'function-history)
> > +                                 (assq f byte-compile-function-environment))
> >                         (push f byte-compile-noruntime-functions)))))))))))))
> 
> Seems appropriate (and fixes this bug).
> 
> Actually with that patch the situation looks already quite ok'ish to me.

Please install this on master, and thanks.

bug#64232: 28.2; Incorrect(?) byte compilation warning about ‘ansi-color-apply-on-region’

[Eli Zaretskii]

Ping!  Any reasons this was not yet installed on master?

> Cc: zack@owlfolio.org, 64232@debbugs.gnu.org, monnier@iro.umontreal.ca
> Date: Fri, 30 Jun 2023 09:00:33 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Michael Heerdegen <michael_heerdegen@web.de>
> > Cc: 64232@debbugs.gnu.org,  eliz@gnu.org,  zack@owlfolio.org
> > Date: Fri, 30 Jun 2023 06:02:36 +0200
> > 
> > Stefan Monnier <monnier@iro.umontreal.ca> writes:
> > 
> > > Someone™ should sit down and figure out how to make `bytecomp.el` keep
> > > track of those things more reliably/predictably.
> > > In the mean time, maybe we can simply tweak `byte-compile-eval` so it
> > > never adds to `byte-compile-noruntime-functions` functions which have
> > > already been seen/declared during the current compilation?
> > >
> > >
> > > diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
> > > index 99202185d8d..cfec4b3be06 100644
> > > --- a/lisp/emacs-lisp/bytecomp.el
> > > +++ b/lisp/emacs-lisp/bytecomp.el
> > > @@ -1128,7 +1128,8 @@ byte-compile-eval
> > >  		     ;; we arguably should add it to b-c-noruntime-functions,
> > >                       ;; but it's not clear it's worth the trouble
> > >  		     ;; trying to recognize that case.
> > > -		     (unless (get f 'function-history)
> > > +		     (unless (or (get f 'function-history)
> > > +                                 (assq f byte-compile-function-environment))
> > >                         (push f byte-compile-noruntime-functions)))))))))))))
> > 
> > Seems appropriate (and fixes this bug).
> > 
> > Actually with that patch the situation looks already quite ok'ish to me.
> 
> Please install this on master, and thanks.
> 
> 
> 
> 

bug#64232: 28.2; Incorrect(?) byte compilation warning about ‘ansi-color-apply-on-region’

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> > > --- a/lisp/emacs-lisp/bytecomp.el
>> > > +++ b/lisp/emacs-lisp/bytecomp.el
>> > > @@ -1128,7 +1128,8 @@ byte-compile-eval
>> > >  		     ;; we arguably should add it to b-c-noruntime-functions,
>> > >                       ;; but it's not clear it's worth the trouble
>> > >  		     ;; trying to recognize that case.
>> > > -		     (unless (get f 'function-history)
>> > > +		     (unless (or (get f 'function-history)
>> > > +                                 (assq f byte-compile-function-environment))
>> > >                         (push f byte-compile-noruntime-functions)))))))))))))
>> > 
>> > Seems appropriate (and fixes this bug).
>> > Actually with that patch the situation looks already quite ok'ish to me.
>> Please install this on master, and thanks.
> Ping!  Any reasons this was not yet installed on master?

Oops, sorry.  Pushed,


        Stefan

bug#64232: 28.2; Incorrect(?) byte compilation warning about ‘ansi-color-apply-on-region’

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: michael_heerdegen@web.de,  zack@owlfolio.org,  64232-done@debbugs.gnu.org
> Date: Fri, 07 Jul 2023 12:10:41 -0400
> 
> >> > > --- a/lisp/emacs-lisp/bytecomp.el
> >> > > +++ b/lisp/emacs-lisp/bytecomp.el
> >> > > @@ -1128,7 +1128,8 @@ byte-compile-eval
> >> > >  		     ;; we arguably should add it to b-c-noruntime-functions,
> >> > >                       ;; but it's not clear it's worth the trouble
> >> > >  		     ;; trying to recognize that case.
> >> > > -		     (unless (get f 'function-history)
> >> > > +		     (unless (or (get f 'function-history)
> >> > > +                                 (assq f byte-compile-function-environment))
> >> > >                         (push f byte-compile-noruntime-functions)))))))))))))
> >> > 
> >> > Seems appropriate (and fixes this bug).
> >> > Actually with that patch the situation looks already quite ok'ish to me.
> >> Please install this on master, and thanks.
> > Ping!  Any reasons this was not yet installed on master?
> 
> Oops, sorry.  Pushed,

Thanks.