Science to suppress compiler warnings

Science to suppress compiler warnings

[Xavier Maillard]

Hi,

Elisp manual at "Compiler Errors" section (16.6) says we should
conditionalize variable use with a boundp test (same thing for
undefined function) but I find it very unpractical.

I thought (probably was wrong) that:

(eval-when-compile (defvar foo nil))

would do the trick. Is it the correct way to avoid warnings ?

Also while at it, here is what I got when compiling an old
package:

records.el:931:49:Warning: reference to free variable
`records-link-menu-map'

In records-mode:
records.el:1066:23:Warning: assignment to free variable
    `records-link-menu-map'

What is the difference between these two warnings exactly ?
Adding a defvar at the right place fixed that but to feed my
curiosity.

Regards,

Xavier

Re: Science to suppress compiler warnings

[Davis Herring]

> Elisp manual at "Compiler Errors" section (16.6) says we should
> conditionalize variable use with a boundp test (same thing for
> undefined function) but I find it very unpractical.
>
> I thought (probably was wrong) that:
>
> (eval-when-compile (defvar foo nil))
>
> would do the trick. Is it the correct way to avoid warnings ?

That should work if you have confidence that it will be defined (and
non-void) at runtime.  The [f]boundp, of course, will let you react to it
not existing then, if there's a real possibility (as with an old Emacs
version) of it not being there.

> Also while at it, here is what I got when compiling an old
> package:
>
> records.el:931:49:Warning: reference to free variable
> `records-link-menu-map'
>
> In records-mode:
> records.el:1066:23:Warning: assignment to free variable
>     `records-link-menu-map'
>
> What is the difference between these two warnings exactly ?
> Adding a defvar at the right place fixed that but to feed my
> curiosity.

The first is for reading, the second for writing; that's all.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Science to suppress compiler warnings

[Xavier Maillard]

At Tue, 2 Jun 2009 16:36:22 -0700 (PDT),
Davis Herring wrote:

> > records.el:931:49:Warning: reference to free variable
> > `records-link-menu-map'
> >
> > In records-mode:
> > records.el:1066:23:Warning: assignment to free variable
> >     `records-link-menu-map'
> >
> > What is the difference between these two warnings exactly ?
> > Adding a defvar at the right place fixed that but to feed my
> > curiosity.
> 
> The first is for reading, the second for writing; that's all.

Yup, I posted this one too quickly (I should have read it mor
carefully before posting).

RE: Science to suppress compiler warnings

[Drew Adams]

> (eval-when-compile (defvar foo nil))

(eval-when-compile (defvar foo))

You don't give it a value; you just declare it (to the compiler).

> Warning: reference to free variable `records-link-menu-map'
> Warning: assignment to free variable `records-link-menu-map'
> 
> What is the difference between these two warnings exactly ?

The first means the variable is used (referenced) somehow.
The second means that it is assigned to.

E.g., (setq foo bar) refers to variable `bar', and if it's free, then you get
the first warning. (setq bar 5) assigns `bar' a value, which will give you the
second warning (if `bar' is free).

Re: Science to suppress compiler warnings

[Lennart Borgman]

On Wed, Jun 3, 2009 at 1:57 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> (eval-when-compile (defvar foo nil))
>
> (eval-when-compile (defvar foo))
>
> You don't give it a value; you just declare it (to the compiler).

If you check later for a library (which is probably what you normally
want to do as Drew said) you could also do:

  (eval-when-compile (require 'THELIB))

Then you probably have things in your the library you compile like

(defun my-defun ()
   (require 'THELIB nil t)
   (when (featurep 'THELIB) ...)

Re: Science to suppress compiler warnings

[Stefan Monnier]

>> (eval-when-compile (defvar foo nil))
> (eval-when-compile (defvar foo))

Aka just

  (defvar foo)


-- Stefan

Re: Science to suppress compiler warnings

[Xavier Maillard]

At Wed, 03 Jun 2009 01:35:11 -0400,
Stefan Monnier wrote:
> 
> >> (eval-when-compile (defvar foo nil))
> > (eval-when-compile (defvar foo))
> 
> Aka just
> 
>   (defvar foo)

Could you explain to me why ? When does one want to use
(eval-when-compile ...) ? I know at least one for sure, macro
compilation, but why not for variables or even functions ?

Is the byte-compilation process and/or eval-* functions well
covered somewhere in the emacs documentation ? I read a lot,
googled a lot but nothing really helpful (even the elisp manual
is pretty poor on that).

Thank you,

Xavier

Re: Science to suppress compiler warnings

[Stefan Monnier]

>> >> (eval-when-compile (defvar foo nil))
>> > (eval-when-compile (defvar foo))
>> Aka just
>> (defvar foo)
> Could you explain to me why ?

Because (defvar FOO) is defined to do exactly that: tell the compiler to
shut up, while not affecting the runtime at all.


        Stefan

RE: Science to suppress compiler warnings

[Drew Adams]

> >> (eval-when-compile (defvar foo nil))
> > (eval-when-compile (defvar foo))
> 
> Aka just (defvar foo)

Oops, yes, thanks.

> You don't even need eval-when-compile, since toplevel defvars 
> are always seen by the compiler, and a defvar without a value
> never sets the variable.

Re: Science to suppress compiler warnings

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

>> (eval-when-compile (defvar foo nil))
>
> (eval-when-compile (defvar foo))
>
> You don't give it a value; you just declare it (to the compiler).

You don't even need eval-when-compile, since toplevel defvars are always
seen by the compiler, and a defvar without a value never sets the
variable.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Science to suppress compiler warnings

[Xavier Maillard]

At Wed, 03 Jun 2009 10:40:20 +0200,
Andreas Schwab wrote:
> 
> "Drew Adams" <drew.adams@oracle.com> writes:
> 
> >> (eval-when-compile (defvar foo nil))
> >
> > (eval-when-compile (defvar foo))
> >
> > You don't give it a value; you just declare it (to the compiler).
> 
> You don't even need eval-when-compile, since toplevel defvars are always
> seen by the compiler, and a defvar without a value never sets the
> variable.

Thank you that answers my other question to Stefan.

Xavier

Re: Science to suppress compiler warnings

[Xavier Maillard]

At Tue, 2 Jun 2009 16:57:10 -0700,
Drew Adams wrote:
> 
> > (eval-when-compile (defvar foo nil))
> 
> (eval-when-compile (defvar foo))
> 
> You don't give it a value; you just declare it (to the compiler).

Good catch, thank you.

Science to suppress compiler warnings

[Stephen J. Turnbull]

Xavier Maillard writes:

 > Elisp manual at "Compiler Errors" section (16.6) says we should
 > conditionalize variable use with a boundp test (same thing for
 > undefined function) but I find it very unpractical.

If this is related to your work on supporting old versions of Emacs,
my advice is "live with it".  Either use the runtime test if it's an
Emacs-defined variable, or use an appropriate `defvar' or `defconst'
to initialize the variable.

Suppressing compiler warnings is very likely to lead to runtime
errors, often intermittent ones.  Eg, there may be an unusual code
path that leads to reference to a void variable very early in an Emacs
session.  Boom!  But unless you type that exact sequence of commands
immediately after starting Emacs, something requires the relevant
library, and no problem can be found.

Such bugs are quite hard to diagnose, even to localize, if the user is
not an Emacs expert.  A boundp check with a good error message, or a
proper initialization with `defvar', will prevent or at least help
diagnose a lot of problems.

 > I thought (probably was wrong) that:
 > 
 > (eval-when-compile (defvar foo nil))
 > 
 > would do the trick. Is it the correct way to avoid warnings ?

If you don't understand what this does, I have to recommend avoiding
this trick.  It's a dangerous optimization, not a fix.

This kind of warning suppression is a *white lie* to Lisp.  If you
know what you're doing, and you're desperate for space savings, it may
be useful.  Otherwise, you're just asking for trouble.  Just defvar at
loadtime (costless) or require the defining library (usually at a
fairly small space cost).

Re: Science to suppress compiler warnings

[Lennart Borgman]

On Wed, Jun 3, 2009 at 6:43 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Xavier Maillard writes:
>
>  > Elisp manual at "Compiler Errors" section (16.6) says we should
>  > conditionalize variable use with a boundp test (same thing for
>  > undefined function) but I find it very unpractical.
>
> If this is related to your work on supporting old versions of Emacs,
> my advice is "live with it".  Either use the runtime test if it's an
> Emacs-defined variable, or use an appropriate `defvar' or `defconst'
> to initialize the variable.
>
> Suppressing compiler warnings is very likely to lead to runtime
> errors, often intermittent ones.  Eg, there may be an unusual code
> path that leads to reference to a void variable very early in an Emacs
> session.  Boom!  But unless you type that exact sequence of commands
> immediately after starting Emacs, something requires the relevant
> library, and no problem can be found.
>
> Such bugs are quite hard to diagnose, even to localize, if the user is
> not an Emacs expert.  A boundp check with a good error message, or a
> proper initialization with `defvar', will prevent or at least help
> diagnose a lot of problems.


But if you combine (defvar foo) with tests everywhere foo is used you
should be safe ...