byte-compile-maybe-guarded

byte-compile-maybe-guarded

[Glenn Morris]

Dan,


FYI I've restored the code in byte-compile-maybe-guarded that you
commented out 2007-11-10. Without this code, a false warning is
produced in the following case:

foo.el:
(defsubst foo ()
  (if (featurep 'xemacs) (setq foo t)))   ; foo is a free variable
(provide 'foo)

bar.el:
(require 'foo)
(foo)


emacs -Q -batch --eval "(add-to-list 'load-path default-directory)" \
   -f batch-byte-compile bar.el

In toplevel form:
bar.el:2:2:Warning: assignment to free variable `foo'

Re: byte-compile-maybe-guarded

[Dan Nicolaescu]

Glenn Morris <rgm@gnu.org> writes:

  > FYI I've restored the code in byte-compile-maybe-guarded that you
  > commented out 2007-11-10. Without this code, a false warning is
  > produced in the following case:

Although restoring that code fixes the warning that you showed, is it
the right thing to do?

  > foo.el:
  > (defsubst foo ()
  >   (if (featurep 'xemacs) (setq foo t)))   ; foo is a free variable
  > (provide 'foo)
  > 
  > bar.el:
  > (require 'foo)
  > (foo)
  > 
  > 
  > emacs -Q -batch --eval "(add-to-list 'load-path default-directory)" \
  >    -f batch-byte-compile bar.el

If the defsubst in foo.el to is:

(defsubst foo ()
  (if (and t (featurep 'xemacs)) (setq foo t)))   ; foo is a free variable

the warning is still produced even after your change...

Re: byte-compile-maybe-guarded

[Stefan Monnier]

> FYI I've restored the code in byte-compile-maybe-guarded that you
> commented out 2007-11-10.

I don't think it's the right place to fix it.
But at least, now we can add a clear comment describing the problem.


        Stefan

Re: byte-compile-maybe-guarded

[Stefan Monnier]

> FYI I've restored the code in byte-compile-maybe-guarded that you
> commented out 2007-11-10. Without this code, a false warning is
> produced in the following case:

> foo.el:
> (defsubst foo ()
>   (if (featurep 'xemacs) (setq foo t)))   ; foo is a free variable
> (provide 'foo)

> bar.el:
> (require 'foo)
> (foo)


It seems the problem is in the (lack of) optimization of forms like

  ((lambda (args) body) exps)

You can see it by byte-compiling

  (defun foo ()
    ((lambda () (if (featurep 'xemacs) (setq foo t)))))

I.e. the patch below seems to fix the problem the right way.
I'm just not 100% sure it can't introduce an infinite optimization loop.


        Stefan


--- orig/lisp/emacs-lisp/byte-opt.el
+++ mod/lisp/emacs-lisp/byte-opt.el
@@ -383,7 +383,9 @@
 		form))
 	  ((or (byte-code-function-p fn)
 	       (eq 'lambda (car-safe fn)))
-	   (byte-compile-unfold-lambda form))
+           (byte-optimize-form
+            (byte-compile-unfold-lambda form)
+            for-effect))
 	  ((memq fn '(let let*))
 	   ;; recursively enter the optimizer for the bindings and body
 	   ;; of a let or let*.  This for depth-firstness: forms that

Re: byte-compile-maybe-guarded

[Glenn Morris]

Stefan Monnier wrote:

>> FYI I've restored the code in byte-compile-maybe-guarded that you
>> commented out 2007-11-10.
>
> I don't think it's the right place to fix it.
> But at least, now we can add a clear comment describing the problem.

I confess I didn't think about it much. I thought Dan commented it out
because it was doing nothing, so when I saw it was doing something, I
put it back.