strange byte compiler behavior

strange byte compiler behavior

[Dan Nicolaescu]

When compiling vc-cvs in batch mode (cd emacs/lisp; make recompile) 
no warning is issued. 

When compiling it with M-x byte-compile-file this warning is issued:

In vc-cvs-register:
vc-cvs.el:301:41:Warning: reference to free variable `file'


The warning is correct, it looks like vc-cvs-register has a bug, it
should look at `files', not `file'.

Any idea why this warning is not issued in batch mode?

Re: strange byte compiler behavior

[martin rudalics]

There's still the occurrence of `file' in `vc-next-action' I reported in

http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg00872.html

      ((stringp state)
       (let ((revision
	     (if verbose
		 (read-string "Revision to steal: ")
	       (vc-working-revision file))))
	                            ^^^^
	(dolist (file files) (vc-steal-lock file revision state))))

Re: strange byte compiler behavior

[Dan Nicolaescu]

martin rudalics <rudalics@gmx.at> writes:

  > There's still the occurrence of `file' in `vc-next-action' I reported in
  > 
  > http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg00872.html
  > 
  >      ((stringp state)
  >       (let ((revision
  > 	     (if verbose
  > 		 (read-string "Revision to steal: ")
  > 	       (vc-working-revision file))))
  > 	                            ^^^^
  > 	(dolist (file files) (vc-steal-lock file revision state))))

Interesting. No warning is ever issued for this one, and an incorrect
one is issued for another occurrence of `file' in that file in
interactive mode.

[I think is better to refrain from fixing the code until the byte
compiler issues are analyzed].

Re: strange byte compiler behavior

[martin rudalics]

> Interesting. No warning is ever issued for this one, and an incorrect
> one is issued for another occurrence of `file' in that file in
> interactive mode.

IIRC, it's a known issue with the byte-compiler.  The "incorrect"
warning you see is the warning for the one I mention.

Re: strange byte compiler behavior

[Dan Nicolaescu]

martin rudalics <rudalics@gmx.at> writes:

  > > Interesting. No warning is ever issued for this one, and an incorrect
  > > one is issued for another occurrence of `file' in that file in
  > > interactive mode.
  > 
  > IIRC, it's a known issue with the byte-compiler.  The "incorrect"
  > warning you see is the warning for the one I mention.

Doubtful, I fixed that issue in my tree and I still get a warning.

Re: strange byte compiler behavior

[martin rudalics]

 >   > IIRC, it's a known issue with the byte-compiler.  The "incorrect"
 >   > warning you see is the warning for the one I mention.
 >
 > Doubtful, I fixed that issue in my tree and I still get a warning.

Because there's yet another one here:

	      (setq revision (read-string "New revision or backend: "))
	      (let ((vsym (intern (upcase revision))))
		(if (member vsym vc-handled-backends)
		    (vc-transfer-file file vsym)
		                      ^^^^
		  (vc-checkin ready-for-commit revision))))))))

Re: strange byte compiler behavior

[Dan Nicolaescu]

Dan Nicolaescu <dann@ics.uci.edu> writes:

  > When compiling vc-cvs in batch mode (cd emacs/lisp; make recompile) 
  > no warning is issued. 
  > 
  > When compiling it with M-x byte-compile-file this warning is issued:
  > 
  > In vc-cvs-register:
  > vc-cvs.el:301:41:Warning: reference to free variable `file'
  > 
  > 
  > The warning is correct, it looks like vc-cvs-register has a bug, it
  > should look at `files', not `file'.
  > 
  > Any idea why this warning is not issued in batch mode?


Investigating a bit: 

1. 
cd lisp ; make recompile 

which runs: -batch --no-site-file --multibyte --eval "(batch-byte-recompile-directory 0)"
does NOT warn

but running: 

-batch --no-site-file --multibyte --eval '(byte-compile-file "vc-cvs.el")'

warns

2. the warning is related to the name `file', if the variable is renamed
`file1' both the batch mode and interactive mode produce a warning.

3. Adding this:

   (message "var %s boundp %s" var  (boundp var))
to `byte-compile-variable-ref' shows that `file' is bound for the function
in question.  Which would explain the results. 
Any idea what causes `file' to be bound? (Assuming that boundp is the
correct test in that context...)

Re: strange byte compiler behavior

[martin rudalics]

 > which runs: -batch --no-site-file --multibyte --eval "(batch-byte-recompile-directory 0)"
 > does NOT warn

What happens when you comment out the disjunct

(memq var byte-compile-free-references)

from `byte-compile-variable-ref'?  Alternatively what is the value of
that variable when you do not get the warning?  Also, could you try the
same with just the file in question in the directory you recompile?

 >    (message "var %s boundp %s" var  (boundp var))
 > to `byte-compile-variable-ref' shows that `file' is bound for the function
 > in question.  Which would explain the results.
 > Any idea what causes `file' to be bound? (Assuming that boundp is the
 > correct test in that context...)

Since `byte-compile-variable-ref' has

	  (or (boundp var)

it would be interesting _where_ in `byte-compile-variable-ref' you
inserted that.

Re: strange byte compiler behavior

[Dan Nicolaescu]

martin rudalics <rudalics@gmx.at> writes:

  > > which runs: -batch --no-site-file --multibyte --eval "(batch-byte-recompile-directory 0)"
  > > does NOT warn
  > 
  > What happens when you comment out the disjunct
  > 
  > (memq var byte-compile-free-references)
  > 
  > from `byte-compile-variable-ref'?  Alternatively what is the value of
  > that variable when you do not get the warning?  

I can't try this right now, but why would it be relevant. 
Because (boundp var) is true, then (or (boundp var) BLAH) is true and
BLAH does not get executed after that. 



  > Also, could you try the same with just the file in question in the
  > directory you recompile?

I tried that before, no difference. 

  > >    (message "var %s boundp %s" var  (boundp var))
  > > to `byte-compile-variable-ref' shows that `file' is bound for the function
  > > in question.  Which would explain the results.
  > > Any idea what causes `file' to be bound? (Assuming that boundp is the
  > > correct test in that context...)
  > 
  > Since `byte-compile-variable-ref' has
  > 
  > 	  (or (boundp var)
  > 
  > it would be interesting _where_ in `byte-compile-variable-ref' you
  > inserted that.

At the beginning of the function, but as I explained above, it is not
relevant.

Re: strange byte compiler behavior

[Dan Nicolaescu]

Dan Nicolaescu <dann@ics.uci.edu> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  >   > When compiling vc-cvs in batch mode (cd emacs/lisp; make recompile) 
  >   > no warning is issued. 
  >   > 
  >   > When compiling it with M-x byte-compile-file this warning is issued:
  >   > 
  >   > In vc-cvs-register:
  >   > vc-cvs.el:301:41:Warning: reference to free variable `file'
  >   > 
  >   > 
  >   > The warning is correct, it looks like vc-cvs-register has a bug, it
  >   > should look at `files', not `file'.
  >   > 
  >   > Any idea why this warning is not issued in batch mode?
  > 
  > 
  > Investigating a bit: 
  > 
  > 1. 
  > cd lisp ; make recompile 
  > 
  > which runs: -batch --no-site-file --multibyte --eval "(batch-byte-recompile-directory 0)"
  > does NOT warn
  > 
  > but running: 
  > 
  > -batch --no-site-file --multibyte --eval '(byte-compile-file "vc-cvs.el")'
  > 
  > warns
  > 
  > 2. the warning is related to the name `file', if the variable is renamed
  > `file1' both the batch mode and interactive mode produce a warning.
  > 
  > 3. Adding this:
  > 
  >    (message "var %s boundp %s" var  (boundp var))
  > to `byte-compile-variable-ref' shows that `file' is bound for the function
  > in question.  Which would explain the results. 
  > Any idea what causes `file' to be bound? (Assuming that boundp is the
  > correct test in that context...)

`byte-recompile-directory' contains a form: "(dolist (file files)" that
calls `byte-compile-file'. As a consequence (boundp 'file) to be t when
`byte-compile-file' is called.

What is TRTD here?

Re: strange byte compiler behavior

[David Kastrup]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Dan Nicolaescu <dann@ics.uci.edu> writes:
>
>   > Investigating a bit: 
>   > 
>   > 1. 
>   > cd lisp ; make recompile 
>   > 
>   > which runs: -batch --no-site-file --multibyte --eval "(batch-byte-recompile-directory 0)"
>   > does NOT warn
>
> `byte-recompile-directory' contains a form: "(dolist (file files)" that
> calls `byte-compile-file'. As a consequence (boundp 'file) to be t when
> `byte-compile-file' is called.
>
> What is TRTD here?

Lexical scope.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: strange byte compiler behavior

[Richard Stallman]

    `byte-recompile-directory' contains a form: "(dolist (file files)" that
    calls `byte-compile-file'. As a consequence (boundp 'file) to be t when
    `byte-compile-file' is called.

That's a joke on us.

The easy solution is to rename the variables in `byte-recompile-directory'
and maybe a few other relevant functions.

A deeper solution would be to get rid of the boundp test.

I'm sure it was added for a reason -- there must have been lots of
spurious warnings without that boundp test.  But nowadays we have done
a lot to eliminate such warnings with defvars.  Perhaps now if we get
rid of that boundp test the results would be ok.

Does someone want to try it?

Re: strange byte compiler behavior

[Stefan Monnier]

> A deeper solution would be to get rid of the boundp test.

> I'm sure it was added for a reason -- there must have been lots of
> spurious warnings without that boundp test.  But nowadays we have done
> a lot to eliminate such warnings with defvars.  Perhaps now if we get
> rid of that boundp test the results would be ok.

> Does someone want to try it?

No need to try: the boundp test is still needed to catch the case of
a variable defined globally in all cases (e.g. in C code or in preloaded
packages) as well as for variables defined in packages that are
`require'd (or loaded transitively by some of the `require'd packages).


        Stefan

Re: strange byte compiler behavior

[Richard Stallman]

    No need to try: the boundp test is still needed to catch the case of
    a variable defined globally in all cases (e.g. in C code or in preloaded
    packages) as well as for variables defined in packages that are
    `require'd (or loaded transitively by some of the `require'd packages).

Would you please fill in the gaps in that argument?
I don't see why it is needed for those.  Shouldn't those
variables be defvar'd?

Re: strange byte compiler behavior

[Stefan Monnier]

>     No need to try: the boundp test is still needed to catch the case of
>     a variable defined globally in all cases (e.g. in C code or in preloaded
>     packages) as well as for variables defined in packages that are
>     `require'd (or loaded transitively by some of the `require'd packages).

> Would you please fill in the gaps in that argument?
> I don't see why it is needed for those.  Shouldn't those
> variables be defvar'd?

They are, but elsewhere and the byte-compiler only knows about it via
`boundp': it doesn't keep its own list of defvar'd variables.


        Stefan

Re: strange byte compiler behavior

[martin rudalics]

> They are, but elsewhere and the byte-compiler only knows about it via
> `boundp': it doesn't keep its own list of defvar'd variables.

aka `heisenboundp'

Re: strange byte compiler behavior

[Richard Stallman]

    They are, but elsewhere and the byte-compiler only knows about it via
    `boundp': it doesn't keep its own list of defvar'd variables.

Indeed, that is true.  But we COULD make it check for a variable doc
string instead.

The effect would be that variables defvar'd in another file with no
doc string would get warnings.  Maybe that is not a bad result.