Re: On elisp running native

[Andrea Corallo]

Adam Porter <address@hidden> writes:

> Hi Andrea,

Hi Adam,

> I did encounter a minor issue related to macro-expansion and loading
> that may be my fault.  When I tried to (require 'org-ql) or call a
> function that is autoloaded from it, I got an error saying that the .eln
> file did not provide the org-ql feature.  I surmised that meant that the
> file hadn't been compiled properly, so I looked at the async compilation
> log and saw an error saying that the variable org-ql-predicates was not
> defined.  At this URL you can see a macro definition,
> org-ql--def-plain-query-fn, and the call to it that's wrapped in
> cl-eval-when to ensure it works properly with the byte-compiler:
>
> https://github.com/alphapapa/org-ql/blob/06481960764a55a36d886e1db79a58258d5d2ffb/org-ql.el#L1671
>
> The macro uses the value of org-ql-predicates, which is defined here:
>
> https://github.com/alphapapa/org-ql/blob/06481960764a55a36d886e1db79a58258d5d2ffb/org-ql.el#L126
>
> But when the org-ql--defpred macro:
>
> https://github.com/alphapapa/org-ql/blob/06481960764a55a36d886e1db79a58258d5d2ffb/org-ql.el#L140
>
> ...is called, it adds to that variable.  So all of that works with the
> byte-compiler, but apparently not with the native compilation.

I took a look to the issue.  I think issue reduces to:

#+BEGIN_SRC lisp
(defvar repro-xxx 123)

(cl-eval-when (compile load eval)
  (defmacro repro-macro ()
    "foo"
    repro-xxx)
  (repro-macro))

(provide 'repro)
#+END_SRC

And this can be further reduced to:

#+BEGIN_SRC lisp
(defvar repro-xxx)

(cl-eval-when (compile)
  repro-xxx)

(provide 'repro)
#+END_SRC

Both of these do *not* byte-compile.  I'm not an expert but to me it
makes sense that `repro-xxx' is not defined in the compilation
enviroment and I think the byte-compiler is very much correct in
signaling the error.

The reason why your code is byte-compiled correctly during the package
installation is that apparently package.el is loading the non compiled
version *before* running the byte-compiler through
`package--load-files-for-activation'.  As a consequence when the
byte-compiler runs the defvar already took effect.

I'm not sure this is what we want in general because it can mask issues
but I'm new to Emacs development so there's very possibly a reason to
that.  Perhaps someone will comment this.

I think your fix to wrap the defvar is correct.

That said we have to fix the native compiler that not only is not
signaling in a sufficiently visible way the error, but is also producing
an eln just ignoring it :)

I'll look into this second point as next.

Thanks

  Andrea

--
address@hidden