From: Alan Mackenzie <acm@muc.de>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 21466@debbugs.gnu.org
Subject: bug#21466: [PATCH] Avoid defining (temporarily) vars and functions
Date: Sat, 26 Mar 2022 19:51:35 +0000 [thread overview]
Message-ID: <Yj9ux7L4eyUQvg2q@ACM> (raw)
In-Reply-To: <877d8gd5k3.fsf@gnus.org>
Hello, Lars.
On Sat, Mar 26, 2022 at 17:47:24 +0100, Lars Ingebrigtsen wrote:
> Alan Mackenzie <acm@muc.de> writes:
> > These explain the "free variable" warnings for the variables and the
> > "defined multiple times" warnings for the functions.
> > To sort out this bug properly, we really need Lisp functions equivalent
> > to C's extern. (defvar foo) and (declare-function 'foo nil) currently
> > don't fill this need.
> I had a brief look at a couple of the warnings (after the patch), and it
> looks like the warnings could be resolved by just removing the
> cc-bytecomp-deffun (and rearranging the code order).
The whole patch was predicated on:
>>>> It might have made sense back in the days when the
>>>> byte-compiler did not offer built-in ways to silence those
>>>> warnings, but nowadays we can do better.
I'm not convinced that what the byte compiler currently offers is
"better", if that involves having to rearrange things in a source file.
And even then, that would only resolve two of the ~15 warning messages.
By contrast, leaving things alone is not causing any trouble, and seems
unlikely to cause trouble in the near future.
There is currently no clean way of declaring a symbol's variable or
function cell as bound for the byte compiler. Perhaps there should be.
> --
> (domestic pets only, the antidote for overdose, milk.)
> bloggy blog: http://lars.ingebrigtsen.no
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2022-03-26 19:51 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-12 3:36 bug#21466: [PATCH] Avoid defining (temporarily) vars and functions Stefan Monnier
2015-10-29 13:09 ` Stefan Monnier
2019-11-06 1:29 ` Stefan Kangas
2021-05-10 11:45 ` Lars Ingebrigtsen
2021-05-11 20:34 ` Alan Mackenzie
[not found] ` <YJrqVlJR4iMvf2s1@ACM>
2021-05-11 22:03 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-07-23 13:14 ` Lars Ingebrigtsen
2021-07-23 15:01 ` Glenn Morris
2021-07-24 10:26 ` Lars Ingebrigtsen
2022-03-23 20:13 ` Lars Ingebrigtsen
2022-03-25 21:09 ` Alan Mackenzie
2022-03-26 14:45 ` Alan Mackenzie
2022-03-26 16:47 ` Lars Ingebrigtsen
2022-03-26 19:51 ` Alan Mackenzie [this message]
2022-03-29 12:26 ` Lars Ingebrigtsen
2022-03-29 21:02 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
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=Yj9ux7L4eyUQvg2q@ACM \
--to=acm@muc.de \
--cc=21466@debbugs.gnu.org \
--cc=larsi@gnus.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).