Re: master bf21025: * lisp/emacs-lisp/bytecomp.el: Remember location of unresolved calls

[Stefan Monnier]

> 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