unexpected byte-compiler behaviour

unexpected byte-compiler behaviour

[hector]

Hi.

I'm trying to compile a file and it's driving me crazy.
At some point of the file I'm reading unexpected messages:

lyqi.el:137:1:Warning: `(abbrev :initarg :abbrev)' is a malformed function

There's something weird going on here. So I write a nonsense function call
at top level:
(djghalkjhg)

The byte-compiler just skips this and keeps showing the first message.

When I cut the file at this point the compiler says what I expect:

tmp.el:136:1:Warning: the function `djghalkjhg' is not known to be defined.

How can this be?

This leads me to think that the parser is doing more than one pass since
a text after this point is affecting compilation at this point.

If this is true, what the heck is causing it to not report that
function "djghalkjhg" is not defined?

Any ideas?

Re: unexpected byte-compiler behaviour

[John Mastro]

hector <hectorlahoz@gmail.com> wrote:
> I'm trying to compile a file and it's driving me crazy.
> At some point of the file I'm reading unexpected messages:
>
> lyqi.el:137:1:Warning: `(abbrev :initarg :abbrev)' is a malformed function
>
> There's something weird going on here. So I write a nonsense function call
> at top level:
> (djghalkjhg)
>
> The byte-compiler just skips this and keeps showing the first message.
>
> When I cut the file at this point the compiler says what I expect:
>
> tmp.el:136:1:Warning: the function `djghalkjhg' is not known to be defined.
>
> How can this be?
>
> This leads me to think that the parser is doing more than one pass since
> a text after this point is affecting compilation at this point.
>
> If this is true, what the heck is causing it to not report that
> function "djghalkjhg" is not defined?

In Emacs 25.1, I see the behavior you would expect. With this content in
a file test.el:

    ;; test.el

    ((abbrev :initarg :abbrev) 'foo)

    (djghalkjhg)

I call `byte-compile-file' and see these warnings:

    Compiling file /tmp/test.el at Thu Mar  9 10:14:23 2017
    Entering directory ‘/tmp/’
    test.el:3:1:Warning: ‘(abbrev :initarg :abbrev)’ is a malformed function

    In end of data:
    test.el:6:1:Warning: the function ‘djghalkjhg’ is not known to be defined.

Warnings don't cause the byte compiler to stop, so you should indeed see
both warnings, as I do.

        John

Re: unexpected byte-compiler behaviour

[John Mastro]

John Mastro <john.b.mastro@gmail.com> wrote:
> Warnings don't cause the byte compiler to stop, so you should indeed
> see both warnings, as I do.

Maybe you have `byte-compile-error-on-warn' set to non-nil?

        John

Re: unexpected byte-compiler behaviour

[hector]

On Thu, Mar 09, 2017 at 10:20:21AM -0800, John Mastro wrote:
> John Mastro <john.b.mastro@gmail.com> wrote:
> > Warnings don't cause the byte compiler to stop, so you should indeed
> > see both warnings, as I do.
> 
> Maybe you have `byte-compile-error-on-warn' set to non-nil?

No, I don't

Re: unexpected byte-compiler behaviour

[hector]

Thank you for your reply.

One of the problems here is that I'm thinking in C. That's where I come
from and sometimes it's hard to get accustomed to a new language.

You don't need to define a function before it is called. That's why
the "function is not defined" message is delayed until the end of parsing.

I think perhaps I should use "(require 'eieio):

(defclass lyqi-abbrev ()
  ((abbrev :initarg :abbrev)
   (collection :initarg :collection)
   (start-position :initarg :start-position)))

But then, is "defclass" defined even if I don't require eieio?

Re: unexpected byte-compiler behaviour

[John Mastro]

hector <hectorlahoz@gmail.com> wrote:
> One of the problems here is that I'm thinking in C. That's where I come
> from and sometimes it's hard to get accustomed to a new language.
>
> You don't need to define a function before it is called. That's why
> the "function is not defined" message is delayed until the end of parsing.

Functions do need to be defined before they're called, just not before
the call is compiled. However, macros (like defclass) are expanded at
compile time, so they need to be defined before then.

> I think perhaps I should use "(require 'eieio):
>
> (defclass lyqi-abbrev ()
>   ((abbrev :initarg :abbrev)
>    (collection :initarg :collection)
>    (start-position :initarg :start-position)))
>
> But then, is "defclass" defined even if I don't require eieio?

Yes - EIEIO isn't preloaded, and defclass isn't autoloaded, so you
should (require 'eieio).

You can test this by starting a fresh Emacs with "emacs -Q", then
evaluate (fboundp 'defclass), which will return nil. Then evaluate
(require 'eieio), followed by (fboundp 'defclass) again, which will now
return t.

As an aside: Often if you're only using a macro like defclass, it would
be enough to use (eval-when-compile (require 'eieio)), because the
definition is only needed at compile-time. However, from a quick look I
think the expansion of defclass will need EIEIO at runtime (e.g. the
call to eieio-defclass-internal), so EIEIO is needed at both
compile-time and run-time and thus a full (require 'eieio) is called
for.

        John

Re: unexpected byte-compiler behaviour

[hector]

On Thu, Mar 09, 2017 at 01:55:12PM -0800, John Mastro wrote:
> Functions do need to be defined before they're called, just not before
> the call is compiled. However, macros (like defclass) are expanded at
> compile time, so they need to be defined before then.

So basically linking is done, not at compilation like in C, but dynamically
at run time. I think I get it. Thanks a lot.

Could it be that my environment (loaded libraries) is affecting compilation?
Is it advisable to run Emacs with -Q?

Re: unexpected byte-compiler behaviour

[John Mastro]

hector <hectorlahoz@gmail.com> wrote:
> So basically linking is done, not at compilation like in C, but
> dynamically at run time. I think I get it. Thanks a lot.

Yeah, I think that's a fair description.

> Could it be that my environment (loaded libraries) is affecting
> compilation? Is it advisable to run Emacs with -Q?

Emacs's state can definitely affect compilation, and when macros are
involved it can get a little subtle/confusing.

It's not necessary to use "emacs -Q" on a regular basis (I suspect most
people only do that when debugging a specific problem in a minimal
environment), but it can definitely be helpful to use it for compilation
sometimes (especially after large changes, especially involving macros
used in different files than where they were defined).

To do that, you could either launch an "emacs -Q" and then use e.g.
byte-recompile-directory, or install the async package and call
async-byte-recompile-directory, which will launch an "emacs -Q" in the
background.

        John