From: Stefan Monnier <monnier@iro.umontreal.ca>
To: "Basil L. Contovounesios" <contovob@tcd.ie>
Cc: emacs-devel@gnu.org
Subject: Re: master bf21025: * lisp/emacs-lisp/bytecomp.el: Remember location of unresolved calls
Date: Thu, 25 Mar 2021 13:42:06 -0400 [thread overview]
Message-ID: <jwvlfab9lry.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87ft0j88o2.fsf@tcd.ie> (Basil L. Contovounesios's message of "Thu, 25 Mar 2021 17:06:37 +0000")
> Does that mean this part can be removed, or are its side effects still
> needed somewhere?
>
> diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
> index 0babbbb978..dd8d15e167 100644
> --- a/lisp/emacs-lisp/bytecomp.el
> +++ b/lisp/emacs-lisp/bytecomp.el
> @@ -2190,9 +2190,6 @@ byte-compile-from-buffer
> (byte-compile-toplevel-file-form form)))
> ;; Compile pending forms at end of file.
> (byte-compile-flush-pending)
> - ;; Make warnings about unresolved functions
> - ;; give the end of the file as their position.
> - (setq byte-compile-last-position (point-max))
> (byte-compile-warn-about-unresolved-functions)))
> byte-compile--outbuffer)))
I think so, yes.
> BTW, would we like the effect of declare-function to be local to its
> lexical scope? Would this be feasible?
Yes and yes.
> I guess we'd need a new var to keep track of unresolved fns per scope,
> and merge its remaining contents with the global unresolved and
> noruntime lists when popping scope, or something like that?
Can't remember enough of the code to be able to tell.
> My motivating example is, had I declared tab-bar-height within
> frame-notice-user-settings for --without-x builds, then that would have
> shadowed its later unqualified use in frame-inner-height, leaving
> bug#47234 unnoticed. (Of course the same would be true if the
> declaration were at top-level.)
Similarly, I like to put the `declare-function`s right after `require` when
a function requires a package from its body, but this precision is
currently lost.
> Remembering to support a variety of build configurations is already
> tricky enough, so maybe this will help prevent some subset of bugs.
> Or would it not be worth the effort?
I expect the benefit will be fairly minor (which is why I haven't
looked into it). But don't let that stop you ;-)
Stefan
prev parent reply other threads:[~2021-03-25 17:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20210319223536.5620.7190@vcs0.savannah.gnu.org>
[not found] ` <20210319223537.784692101A@vcs0.savannah.gnu.org>
2021-03-25 17:06 ` master bf21025: * lisp/emacs-lisp/bytecomp.el: Remember location of unresolved calls Basil L. Contovounesios
2021-03-25 17:42 ` Stefan Monnier [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvlfab9lry.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=contovob@tcd.ie \
--cc=emacs-devel@gnu.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.