bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#30635: No compiler warning if code forgets to require cl-lib


From: Stefan Monnier
Subject: bug#30635: No compiler warning if code forgets to require cl-lib
Date: Thu, 22 Mar 2018 18:19:29 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

>>>> There's no compiler warning if a library uses cl-lib without requiring it.
>>>> I assume this is because bytecomp.el requires cl-lib.
>>> Should we apply the patch below?
>> Works for me, thanks.
> Doesn't work for me, OTOH:
[...]
> and if you look at `dir-locals-read-from-dir`, you'll see that it does
> (require 'map) and then uses its `map-merge(-with)`.

And if I tweak dir-locals-read-from-dir so it doesn't require `map`, and
then try to compile a file like gnus-cloud.el where I removed all the
`require`s, I still get:

    % src/emacs --batch --eval "(eval-after-load 'cl-lib '(debug t))"  -f 
batch-byte-compile lisp/gnus/gnus-cloud.el  
    Debugger entered--beginning evaluation of function call form:
      (lambda nil (debug t))()
      [...]
      require(cl-lib)
      byte-code("\300\301!\210\300\302!\210\300\303!\207" [require cl-lib 
macroexp gv] 2)
      cl--defsubst-expand((cl-x) (cl-block epg-context-armor (or 
(cl--struct-epg-context-p cl-x) (signal 'wrong-type-argument (list 'epg-context 
cl-x))) (aref cl-x 4)) nil nil nil context)
      epg-context-armor--cmacro((epg-context-armor context) context)
      apply(epg-context-armor--cmacro (epg-context-armor context) context)
      gv-get((epg-context-armor context) #f(compiled-function (getter setter) 
#<bytecode 0x57f35d>))
      [...]
      macroexpand-all((defalias 'gnus-cloud-encode-data ...) ...)
      [...]
      byte-compile-recurse-toplevel((defun gnus-cloud-encode-data ...) ...)

The end result is better tho; if I then add a call to `cl-every` into
that file, I do get a warning of the form:

    gnus/gnus-cloud.el:512:1:Warning: the function ‘cl-every’ might not be
        defined at runtime.

So I pushed the previous two patches to master, since I think they at
least partly fix this bug.


        Stefan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]