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

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

[Basil L. Contovounesios]

[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

monnier@iro.umontreal.ca (Stefan Monnier) writes:

> branch: master
> commit bf210251eadafafd1bf4176127b872030405baa3
> Author: Stefan Monnier <monnier@iro.umontreal.ca>
> Commit: Stefan Monnier <monnier@iro.umontreal.ca>
>
>     * lisp/emacs-lisp/bytecomp.el: Remember location of unresolved calls
>     
>     I've gotten tired of seeing the "function foo not known to be defined"
>     warning without any line number information.  So this patch adds as
>     line number the position of the first use of that function in the file
>     (well, approximately, as usual).
>     
>     (byte-compile-unresolved-functions): Add POSITIONs in the alist.
>     (byte-compile-function-warn): Store the current position in
>     `byte-compile-unresolved-functions`.
>     (byte-compile-arglist-warn): Adjust accordingly.
>     (byte-compile-print-syms): Delete unused function.
>     (byte-compile-warn-about-unresolved-functions): Use the stored position
>     to give more precise warnings.

Does that mean this part can be removed, or are its side effects still
needed somewhere?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: bytecomp.diff --]
[-- Type: text/x-diff, Size: 572 bytes --]

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)))
 

[-- Attachment #3: Type: text/plain, Size: 798 bytes --]


BTW, would we like the effect of declare-function to be local to its
lexical scope?  Would this be feasible?

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?

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.)

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?

Thanks,

-- 
Basil

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