Problems setting byte-compile-warnings to t

Problems setting byte-compile-warnings to t

[Glenn Morris]

Create a file foo.el with first (and only) line:

;; -*- byte-compile-warnings: t; -*-

Then try to byte-compile it:

1.el:Error: Wrong type argument: listp, t

Perhaps one of the `(memq foo byte-compile-warnings)' in bytecomp.el
is being run outside byte-compile-close-variables?

edebug says the error comes from
byte-compile-warn-about-unresolved-functions, but I don't see how.

Re: Problems setting byte-compile-warnings to t

[Glenn Morris]

Glenn Morris wrote:

> Perhaps one of the `(memq foo byte-compile-warnings)' in bytecomp.el
> is being run outside byte-compile-close-variables?

Looking at it some more, the value of byte-compile-warnings set by
byte-compile-close-variables gets clobbered when
byte-compile-insert-header is called. It changes the buffer to
" *Compiler Input", where the buffer local value shadows the value in
the let-binding.

A possible fix might be to alter the value in the " *Compiler Input" buffer:

***************
*** 1682,1687 ****
--- 1687,1697 ----
    ;; Arg of t means don't alter enable-local-variables.
          (normal-mode t)
          (setq filename buffer-file-name))
+       ;; Respect any file local variables.
+       (set (make-local-variable 'byte-compile-warnings)
+            (if (eq byte-compile-warnings t)
+                byte-compile-warning-types
+              byte-compile-warnings))
        ;; Set the default directory, in case an eval-when-compile uses it.
        (setq default-directory (file-name-directory filename)))
      ;; Check if the file's local variables explicitly specify not to

Re: Problems setting byte-compile-warnings to t

[Richard Stallman]

    Looking at it some more, the value of byte-compile-warnings set by
    byte-compile-close-variables gets clobbered when
    byte-compile-insert-header is called. It changes the buffer to
    " *Compiler Input", where the buffer local value shadows the value in
    the let-binding.

It is true that it changes the current buffer, and that is ugly.
Perhaps we should make it use with-current-buffer.

But as soon as it returns, you get to

      (with-current-buffer inbuffer
        ...)

followed by

      (and filename (byte-compile-fix-header filename inbuffer outbuffer))))

and that function does with-current-buffer too.

So where is the code that is affected by the change in the current
buffer made by byte-compile-insert-header?  Is it in the caller of
byte-compile-from-buffer?  I don't see how that could happen, since
the byte-compile-close-variables form has already exited there.

Is it inside byte-compile-insert-header itself?
I don't see where in that function it could be.

Re: Problems setting byte-compile-warnings to t

[Glenn Morris]

Richard Stallman wrote:

> It is true that it changes the current buffer, and that is ugly.
> Perhaps we should make it use with-current-buffer.
>
> But as soon as it returns, you get to
>
>       (with-current-buffer inbuffer
>         ...)
>
> followed by
>
>       (and filename (byte-compile-fix-header filename inbuffer outbuffer))))
>
> and that function does with-current-buffer too.
>
> So where is the code that is affected by the change in the current
> buffer made by byte-compile-insert-header? 

I don't think there is any code that is affected by the buffer change
per se, and I don't think with-current-buffer will help.

The problem seems to be that in inbuffer, byte-compile-warnings has a
buffer-local value (`t') that shadows the value setup by
byte-compile-close-variables. And all the byte-compiling functions use
inbuffer as the current buffer.

So the simplest fix would seem to adjust the buffer-local value in
inbuffer in the same way that byte-compile-close-variables does.

Re: Problems setting byte-compile-warnings to t

[Richard Stallman]

    So the simplest fix would seem to adjust the buffer-local value in
    inbuffer in the same way that byte-compile-close-variables does.

I see a problem with that: such a change would persist after the end
of the compilation.

Here's another idea: add a function byte-compile-memq which always
returns t if the second arg is t, and use that instead of memq to test
membership in byte-compile-warnings.  That avoids the need to alter
data provided by the user.  Do you see any problem with it?

Re: Problems setting byte-compile-warnings to t

[Glenn Morris]

Richard Stallman wrote:

>     So the simplest fix would seem to adjust the buffer-local value in
>     inbuffer in the same way that byte-compile-close-variables does.
>
> I see a problem with that: such a change would persist after the end
> of the compilation.

Yes, but in an internal buffer used only by byte-compilation, so I
don't see the problem. Anyway...

> Here's another idea: add a function byte-compile-memq which always
> returns t if the second arg is t, and use that instead of memq to test
> membership in byte-compile-warnings.  That avoids the need to alter
> data provided by the user.

I installed a changes along these lines: byte-compile-warning-enabled-p.

I also took the opportunity to allow byte-compile-warnings to specify
a list of warnings to _disable_. Useful for compiling emacs-lisp/cl-*, IMO.

Re: Problems setting byte-compile-warnings to t

[Richard Stallman]

    Yes, but in an internal buffer used only by byte-compilation, so I
    don't see the problem. Anyway...

I thought it compiles out of the source buffer sometimes too.

Anyway your changes look good.  Thanks.

Re: Problems setting byte-compile-warnings to t

[Dan Nicolaescu]

Glenn Morris <rgm@gnu.org> writes:

  > Richard Stallman wrote:
  > 
  > >     So the simplest fix would seem to adjust the buffer-local value in
  > >     inbuffer in the same way that byte-compile-close-variables does.
  > >
  > > I see a problem with that: such a change would persist after the end
  > > of the compilation.
  > 
  > Yes, but in an internal buffer used only by byte-compilation, so I
  > don't see the problem. Anyway...
  > 
  > > Here's another idea: add a function byte-compile-memq which always
  > > returns t if the second arg is t, and use that instead of memq to test
  > > membership in byte-compile-warnings.  That avoids the need to alter
  > > data provided by the user.
  > 
  > I installed a changes along these lines: byte-compile-warning-enabled-p.
  > 
  > I also took the opportunity to allow byte-compile-warnings to specify
  > a list of warnings to _disable_. Useful for compiling emacs-lisp/cl-*, IMO.

To take advantage of this new flags I added a new flag to
lisp/Makefile.in: BYTE_COMPILE_EXTRA_FLAGS
It is empty by default, and it is passed to the byte compiler.

It can be used like this:
make bootstrap BYTE_COMPILE_EXTRA_FLAGS="--eval '(setq byte-compile-warnings (quote (not unresolved)))'"
to not show the hundreds of undefined function warnings, this makes it
easier to look for other warnings until a solution is found for
undefined function warnings...