unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Zack Weinberg" <zack@owlfolio.org>
To: "Eli Zaretskii" <eliz@gnu.org>,
	"Stefan Monnier" <monnier@iro.umontreal.ca>
Cc: 64232@debbugs.gnu.org
Subject: bug#64232: 28.2; Incorrect(?) byte compilation warning about ‘ansi-color-apply-on-region’
Date: Sat, 24 Jun 2023 11:15:42 -0400	[thread overview]
Message-ID: <9c38fe1a-ee3a-4b6d-aaa7-33aa4909e331@app.fastmail.com> (raw)
In-Reply-To: <83o7l5yt9k.fsf@gnu.org>

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





  reply	other threads:[~2023-06-24 15:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-22 19:56 bug#64232: 28.2; Incorrect(?) byte compilation warning about ‘ansi-color-apply-on-region’ Zack Weinberg
2023-06-24 11:49 ` Eli Zaretskii
2023-06-24 15:15   ` Zack Weinberg [this message]
2023-06-28  2:10     ` Michael Heerdegen
2023-06-28 13:41       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-29  3:43         ` Michael Heerdegen
2023-06-29  4:51           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-30  4:02             ` Michael Heerdegen
2023-06-30  6:00               ` Eli Zaretskii
2023-07-06  6:43                 ` Eli Zaretskii
2023-07-07 16:10                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-07 18:15                     ` Eli Zaretskii
2023-06-29  4:17 ` Michael Heerdegen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9c38fe1a-ee3a-4b6d-aaa7-33aa4909e331@app.fastmail.com \
    --to=zack@owlfolio.org \
    --cc=64232@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).