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
next prev parent 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).