From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: On elisp running native Date: Wed, 11 Mar 2020 22:04:17 +0000 Message-ID: References: <83tv5mp48l.fsf@gnu.org> <83sgl0lchm.fsf@gnu.org> <83imlwl9vm.fsf@gnu.org> <83o8uegykm.fsf@gnu.org> <74dd94a9-28cb-a5fd-dbc7-ab21009834ad@cs.ucla.edu> <87mu8vjcmm.fsf@alphapapa.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="110318"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: Stefan Monnier , emacs-devel@gnu.org To: Adam Porter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Mar 11 23:05:10 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jC9TR-000SXP-PC for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Mar 2020 23:05:09 +0100 Original-Received: from localhost ([::1]:58614 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jC9TQ-0008Pr-Re for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Mar 2020 18:05:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57293) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jC9Sn-0007Pz-TR for emacs-devel@gnu.org; Wed, 11 Mar 2020 18:04:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jC9Sl-0006uy-IF for emacs-devel@gnu.org; Wed, 11 Mar 2020 18:04:29 -0400 Original-Received: from mx.sdf.org ([205.166.94.20]:50059) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jC9Sl-0006cc-AW for emacs-devel@gnu.org; Wed, 11 Mar 2020 18:04:27 -0400 Original-Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 02BM4HJl020714 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 11 Mar 2020 22:04:18 GMT Original-Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 02BM4HgN012511; Wed, 11 Mar 2020 22:04:17 GMT In-Reply-To: <87mu8vjcmm.fsf@alphapapa.net> (Adam Porter's message of "Thu, 05 Mar 2020 04:54:09 -0600") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 205.166.94.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:245476 Archived-At: Adam Porter 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 -- akrl@sdf.org