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