bytecomp warning for CL functions

bytecomp warning for CL functions

[Dave Love]

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

This helps to debug the use of the CL package at runtime.  It's not
clean but I couldn't see a better way of doing it quickly and simply
and it serves my purposes.  Perhaps someone else can.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 5114 bytes --]

2002-06-19  Dave Love  <fx@gnu.org>

	* emacs-lisp/bytecomp.el (byte-compile-warning-types): Doc fix.
	(byte-compile-warnings): Doc fix.  Add cl-func option.
	(byte-compile-cl-warn): New function.
	(byte-compile-form): Use it.

*** bytecomp.el.~2.85.~	Tue Aug 21 18:01:57 2001
--- bytecomp.el	Wed Jun 19 15:34:15 2002
***************
*** 1,6 ****
  ;;; bytecomp.el --- compilation of Lisp code into byte code
  
! ;; Copyright (C) 1985, 1986, 1987, 1992, 1994, 1998, 2000, 2001
  ;;   Free Software Foundation, Inc.
  
  ;; Author: Jamie Zawinski <jwz@lucid.com>
--- 1,6 ----
  ;;; bytecomp.el --- compilation of Lisp code into byte code
  
! ;; Copyright (C) 1985, 1986, 1987, 1992, 1994, 1998, 2000, 2001, 2002
  ;;   Free Software Foundation, Inc.
  
  ;; Author: Jamie Zawinski <jwz@lucid.com>
***************
*** 326,335 ****
    :group 'bytecomp
    :type 'boolean)
  
  (defconst byte-compile-warning-types
!   '(redefine callargs free-vars unresolved obsolete noruntime))
  (defcustom byte-compile-warnings t
    "*List of warnings that the byte-compiler should issue (t for all).
  Elements of the list may be be:
  
    free-vars   references to variables not in the current lexical scope.
--- 326,340 ----
    :group 'bytecomp
    :type 'boolean)
  
+ ;; `cl-func' isn't here because it probably should only be defined
+ ;; explicitly.
  (defconst byte-compile-warning-types
!   '(redefine callargs free-vars unresolved obsolete noruntime)
!   "The list of warning types used when `byte-compile-warnings' is t.")
  (defcustom byte-compile-warnings t
    "*List of warnings that the byte-compiler should issue (t for all).
+ Actually, t selects all but `cl-func'.
+ 
  Elements of the list may be be:
  
    free-vars   references to variables not in the current lexical scope.
***************
*** 337,349 ****
    callargs    lambda calls with args that don't match the definition.
    redefine    function cell redefined from a macro to a lambda or vice
                versa, or redefined to take a different number of arguments.
!   obsolete    obsolete variables and functions."
    :group 'bytecomp
!   :type '(choice (const :tag "All" t)
  		 (set :menu-tag "Some"
  		      (const free-vars) (const unresolved)
! 		      (const callargs) (const redefined)
! 		      (const obsolete) (const noruntime))))
  
  (defcustom byte-compile-generate-call-tree nil
    "*Non-nil means collect call-graph information when compiling.
--- 342,358 ----
    callargs    lambda calls with args that don't match the definition.
    redefine    function cell redefined from a macro to a lambda or vice
                versa, or redefined to take a different number of arguments.
!   obsolete    obsolete variables and functions.
!   noruntime   functions that may not be defined at runtime (typically
!               defined only under `eval-when-compile').
!   cl-func     calls to runtime functions from the CL package (as opposed to
!               macros and aliases)."
    :group 'bytecomp
!   :type `(choice (const :tag "All" t)
  		 (set :menu-tag "Some"
  		      (const free-vars) (const unresolved)
! 		      (const callargs) (const redefine)
! 		      (const obsolete) (const noruntime) (const cl-func))))
  
  (defcustom byte-compile-generate-call-tree nil
    "*Non-nil means collect call-graph information when compiling.
***************
*** 1126,1131 ****
--- 1135,1161 ----
  		    (delq calls byte-compile-unresolved-functions)))))
        )))
  
+ (defun byte-compile-cl-warn (form)
+   "Warn if FORM is a call of a function from the CL package."
+   (let* ((func (car-safe form))
+ 	 (library
+ 	  (if func
+ 	      (cond ((eq (car-safe func) 'autoload)
+ 		     (nth 1 func))
+ 		    ((symbol-file func))))))
+     (if (and library
+ 	     (string-match "^cl\\>" library)
+ 	     ;; Aliases which won't have been expended at this point.
+ 	     ;; These aren't all aliases of subrs, so not trivial to
+ 	     ;; avoid hardwiring the list.
+ 	     (not (memq func
+ 			'(cl-block-wrapper cl-block-throw values values-list
+ 			  multiple-value-list multiple-value-call nth-value
+ 			  copy-seq first second rest endp cl-member))))
+ 	(byte-compile-warn "Function from cl package called at runtime: %s"
+ 			   func)))
+   form)
+ 
  (defun byte-compile-print-syms (str1 strn syms)
    (cond
     ((cdr syms)
***************
*** 2377,2383 ****
  	       (funcall handler form)
  	     (if (memq 'callargs byte-compile-warnings)
  		 (byte-compile-callargs-warn form))
! 	     (byte-compile-normal-call form))))
  	((and (or (byte-code-function-p (car form))
  		  (eq (car-safe (car form)) 'lambda))
  	      ;; if the form comes out the same way it went in, that's
--- 2407,2415 ----
  	       (funcall handler form)
  	     (if (memq 'callargs byte-compile-warnings)
  		 (byte-compile-callargs-warn form))
! 	     (byte-compile-normal-call form))
! 	   (if (memq 'cl-func byte-compile-warnings)
! 	       (byte-compile-cl-warn form))))
  	((and (or (byte-code-function-p (car form))
  		  (eq (car-safe (car form)) 'lambda))
  	      ;; if the form comes out the same way it went in, that's

Re: bytecomp warning for CL functions

[Miles Bader]

Brilliant!  Er, well, useful, anyway.

Perhaps the doc string for `byte-compile-warnings' should define t as
meaning `all default warnings', and offer another special value, like
`all' to mean `all warnings, no matter what'.

[I can hear Stefan muttering in the background]

-Miles
-- 
I'd rather be consing.

Re: bytecomp warning for CL functions

[Richard Stallman]

That is a good idea--Eli, would you please install it?

I think it would be even better if these warnings were issued by default
whenever the file does not include cl.  Does anyone see a reason not
to do that?

Re: bytecomp warning for CL functions

[Stefan Monnier]

> That is a good idea--Eli, would you please install it?
> 
> I think it would be even better if these warnings were issued by default
> whenever the file does not include cl.  Does anyone see a reason not
> to do that?

Could someone explain to me what this really does ?
I had installed a hack that tries to notice when you call a function
that will not be available at runtime (because the library
was loaded via (eval-when-compile (require 'LIB)) as is done for CL).

It had a bug that I just fixed so it should be a bit more useful now.

In what way does Dave's code differ ?
I notice for example that it warns about code that uses `values' but
since the CVS has replaced the defvalias with a defsubst for `values',
a call to `values' gets replaced during byte-compilation so that
it works just fine even without using CL at runtime.

Admittedly, my hack is just that: a hack.  And it's not reliable.
But it is more genric and covers more cases.  So my question is:
which cases does Dave's code cover that mine doesn't.

What I'm trying to figue out is if there is a way to get the benefits
of Dave's code without having to hard-code any particular list
of functions.


	Stefan

Re: bytecomp warning for CL functions

[Dave Love]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> Could someone explain to me what this really does ?

It detects all (I hope) use of cl functions in the compiled code to
help me debug it.

> I had installed a hack that tries to notice when you call a function
> that will not be available at runtime (because the library
> was loaded via (eval-when-compile (require 'LIB)) as is done for CL).

The cases of interest are when that isn't done, or when you're in a
session that's already loaded it for some reason (e.g. Debian with
various Emacs packages installed) or when there's an explicit autoload
defined for a cl function, &c.  (Real examples.)

> I notice for example that it warns about code that uses `values' but
> since the CVS has replaced the defvalias with a defsubst for `values',
> a call to `values' gets replaced during byte-compilation so that
> it works just fine even without using CL at runtime.

The warning would be useful regardless, if you're trying to make stuff
run in 21.2.  In principle it would also list things problematic in
Emacs 20, but I don't currently need that.

> What I'm trying to figue out is if there is a way to get the benefits
> of Dave's code without having to hard-code any particular list
> of functions.

Sure.  You'd have to check the indirections of aliases to see if they
contained anything defined in the cl files.  Obviously you could
generalize it to deal with packages other than cl, but I can't think
of any for which that would be useful.

Re: bytecomp warning for CL functions

[Richard Stallman]

    > What I'm trying to figue out is if there is a way to get the benefits
    > of Dave's code without having to hard-code any particular list
    > of functions.

That ought to be a small and simple generalization, if we ever want to
make it.  I don't see a need to make it now.  I will install this
code, together with some changes so that these warnings are enabled
automatically whenever the file being compiled does not do (require
'cl) at run time.

Re: bytecomp warning for CL functions

[Juanma Barranquero]

On Tue, 2 Jul 2002 13:45:59 -0600 (MDT), Richard Stallman <rms@gnu.org> wrote:

> I will install this
> code, together with some changes so that these warnings are enabled
> automatically whenever the file being compiled does not do (require
> 'cl) at run time.

So now, having that in .emacs:


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(require 'cl)

(defvar lk-faces-regexp-history nil)

(defadvice list-faces-display (around lk-faces-regexp (arg) activate compile preactivate)
  "If ARG is non-nil, prompt for a regexp and list only
those faces matching the regexp."
  (interactive "P")
  (if arg
      (let* ((regexp (read-string "Faces (regexp): " nil 'lk-faces-regexp-history nil t))
             (faces (if (string= regexp "")
                        (face-list)
                      (delete-if-not #'(lambda (face)
                                         (string-match regexp (symbol-name face)))
                                     (face-list)))))
        (if faces
            (flet ((face-list () faces))
              ad-do-it)
          (message "No faces matching \"%s\"" regexp)))
    ad-do-it))
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;


causes a warning at startup time:

  warning: Function `delete-if-not' from cl package called at runtime

:(


                                                           /L/e/k/t/u

Re: bytecomp warning for CL functions

[Richard Stallman]

    (require 'cl)

    (defvar lk-faces-regexp-history nil)

    (defadvice list-faces-display (around lk-faces-regexp (arg) activate compile preactivate)
      "If ARG is non-nil, prompt for a regexp and list only
    those faces matching the regexp."
      (interactive "P")

I fixed this.

Re: bytecomp warning for CL functions

[Dave Love]

> causes a warning at startup time:
> 
>   warning: Function `delete-if-not' from cl package called at runtime

Comments:

1. The warning is being issued correctly.

2. It's not a good idea to load cl in .emacs -- you can fail to spot
   problems, apart from the bloat.

3. You can turn off implicit compilation by defadvice.

4. defadvice should normally be avoided, apart from the bloat.  If a
   modification you want to make with it is useful, it normally
   indicates the lack of a hook.  I'd just copy the function and
   modify it to avoid sucking in advice in a case like that.

Re: bytecomp warning for CL functions

[Juanma Barranquero]

On 18 Jul 2002 19:48:38 +0100, Dave Love <d.love@dl.ac.uk> wrote:

> Comments:
> 
> 1. The warning is being issued correctly.

Perhaps, but if defadvice has been patched to stop it, that must mean
that it was useless and annoying nonetheless.

> 2. It's not a good idea to load cl in .emacs -- you can fail to spot
>    problems, apart from the bloat.

Oh, come on. I happen to *like* cl and don't consider it a bloat.
Obviously it is a matter of taste, but I feel vaguely offensive that you
answer to a comment about a newly introduced warning saying what I
should do with my .emacs.

As two recent posters on gnu.emacs.help have said:

"You don't need (require 'cl) though I expect like me you have it in
your .emacs file somewhere so you never quite know whether you need it
or not." (Rob Thorpe)

"The proper place for '(require 'cl)' is in your .emacs file, at the top
level :)" (Marco Antoniotti)

> 3. You can turn off implicit compilation by defadvice.

Yes.

> 4. defadvice should normally be avoided, apart from the bloat.

Again, I don't consider it bloat. And I don't know why should I avoid it.
AFAICS there's a policy of avoiding it in modules, but for my own
customizations? What is advice.el intended for, if not that?

> If a modification you want to make with it is useful, it normally
> indicates the lack of a hook.  I'd just copy the function and
> modify it to avoid sucking in advice in a case like that.

Are you suggesting that would be better to copy the eight functions I'm
currently advising to my .emacs and then manually monitoring if they
ever change in their original sources?

Excuse me, but I think you're taking your likes or dislikes as a measure
of what's good for another user...


                                                           /L/e/k/t/u

Re: bytecomp warning for CL functions

[Richard Stallman]

    > causes a warning at startup time:
    > 
    >   warning: Function `delete-if-not' from cl package called at runtime

You can turn off these warnings by setting the variable
byte-compile-error-on-warn to the list of warning types
that you do want.

Re: bytecomp warning for CL functions

[Richard Stallman]

    I had installed a hack that tries to notice when you call a function
    that will not be available at runtime (because the library
    was loaded via (eval-when-compile (require 'LIB)) as is done for CL).

If you can make your code superior to Dave's code that I installed and
then built on, please go ahead and put it in.  His code has a list of
specific CL functions in it, and also checks the function name.
If your code check both kinds of cases and handles both properly, it probably
does everything right.

Re: bytecomp warning for CL functions

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

>     I had installed a hack that tries to notice when you call a function
>     that will not be available at runtime (because the library
>     was loaded via (eval-when-compile (require 'LIB)) as is done for CL).
> 
> If you can make your code superior to Dave's code that I installed and
> then built on, please go ahead and put it in.

As far as I know, they're different things.  My code was specifically
testing CL stuff, even if it would be present at runtime, whereas
Stefan's would check for problems with functions not being available
at runtime generally.  (It never seemed to warn me usefully anyway,
but presumably that was because it was buggy.)

> His code has a list of specific CL functions in it,

That's only a few that are aliases and would otherwise escape.

> and also checks the function name.
> If your code check both kinds of cases and handles both properly, it probably
> does everything right.

Re: bytecomp warning for CL functions

[Richard Stallman]

    As far as I know, they're different things.  My code was specifically
    testing CL stuff, even if it would be present at runtime, whereas
    Stefan's would check for problems with functions not being available
    at runtime generally.

The way I changed your code, it warns about run-time calls to CL
functions from a file that doesn't necessarily load CL at run time.
Stefan, in your code, is the criterion the same: call to a function
in file X, from another file Y that doesn't necessarily load X at run time?

Re: bytecomp warning for CL functions

[Stefan Monnier]

>     As far as I know, they're different things.  My code was specifically
>     testing CL stuff, even if it would be present at runtime, whereas
>     Stefan's would check for problems with functions not being available
>     at runtime generally.
> 
> The way I changed your code, it warns about run-time calls to CL
> functions from a file that doesn't necessarily load CL at run time.
> Stefan, in your code, is the criterion the same: call to a function
> in file X, from another file Y that doesn't necessarily load X at run time?

Mostly, but the devil is in the details.
It complaints when:
the file calls F and F is known to exist during compilation but
not at runtime (because it was made available through (eval-when-compile
(require 'foo))).

But it doesn't work so well if `bar' gets loaded by foo.elc
(and is thus marked as "not available at runtime") but is later
on required explicitly.  I don't check this case.

Also, if `foo' was already loaded when the compilation started,
the results depend on how it was loaded, so it doesn't work
too well with recompile-directory unless the file is either always
required directly or always required through `eval-when-compile'.


	Stefan

Re: bytecomp warning for CL functions

[Richard Stallman]

    But it doesn't work so well if `bar' gets loaded by foo.elc
    (and is thus marked as "not available at runtime") but is later
    on required explicitly.  I don't check this case.

I am having trouble understanding what the scenario is here.

    Also, if `foo' was already loaded when the compilation started,
    the results depend on how it was loaded, so it doesn't work
    too well with recompile-directory unless the file is either always
    required directly or always required through `eval-when-compile'.

This is a very important case, as regards CL.

Re: bytecomp warning for CL functions

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> The way I changed your code, it warns about run-time calls to CL
> functions from a file that doesn't necessarily load CL at run time.

I don't understand.  Surely my change did that anyhow?  It just looked
at the expanded, optimized forms.

Not that I care, as long as you can get useful warnings.

Re: bytecomp warning for CL functions

[Richard Stallman]

    > The way I changed your code, it warns about run-time calls to CL
    > functions from a file that doesn't necessarily load CL at run time.

    I don't understand.  Surely my change did that anyhow?  It just looked
    at the expanded, optimized forms.

No, your code had nothing to test whether the compiled file would load 
cl when loaded.

Re: bytecomp warning for CL functions

[Richard Stallman]

Dave's warning code checks for multiple-value-call,
a name that I remember vaguely from long ago.
However, loading cl.el does not define multiple-value-call.
Is that absence a bug?  If so, would someone like to define it?
(Or tell me what it is supposed to do?)

Re: bytecomp warning for CL functions

[Luc Teirlinck]

Richard Stallman wrote:
   
   Dave's warning code checks for multiple-value-call,
   a name that I remember vaguely from long ago.
   However, loading cl.el does not define multiple-value-call.
   Is that absence a bug?  If so, would someone like to define it?
   (Or tell me what it is supposed to do?)

In Emacs21.2.90 loading cl seems to define multiple-value-call.
Output of C-h f:

multiple-value-call is an alias for `apply' in `cl'.
[Missing arglist.  Please make a bug report.]

Call FUNCTION with our remaining args, using our last arg as list of
args.
Then return the value FUNCTION returns.
Thus, (apply '+ 1 2 '(3 4)) returns 10.

Sincerely,

Luc.

Re: bytecomp warning for CL functions

[Richard Stallman]

    In Emacs21.2.90 loading cl seems to define multiple-value-call.

The comment on that defalias shows it is not entirely correct.
It is better than nothing, so I will put it back in.

Re: bytecomp warning for CL functions

[Dave Love]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> multiple-value-call is an alias for `apply' in `cl'.
> [Missing arglist.  Please make a bug report.]

I fixed that.  I don't know if there's any problem with the code on
the trunk, which I don't understand.

Re: bytecomp warning for CL functions

[Richard Stallman]

    I fixed that.  I don't know if there's any problem with the code on
    the trunk, which I don't understand.

Normally "I fixed that" means you installed a fix in the trunk,
but it sounds like you're saying that is not what you did.
Where did you install the fix that you made?

Re: bytecomp warning for CL functions

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> Where did you install the fix that you made?

On the release branch, where the problem showed up.