From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Lisp files that load cl-lib in problematical ways Date: Sat, 21 Oct 2023 12:05:43 +0000 Message-ID: References: <835y38qvlg.fsf@gnu.org> <87bkcx6eci.fsf@dataswamp.org> <83ttqnm4ti.fsf@gnu.org> <83lebyu5yx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35027"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 21 14:07:23 2023 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 1quAlH-0008rS-Es for ged-emacs-devel@m.gmane-mx.org; Sat, 21 Oct 2023 14:07:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1quAk2-0003Cp-3t; Sat, 21 Oct 2023 08:06:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1quAjw-00039i-VP for emacs-devel@gnu.org; Sat, 21 Oct 2023 08:06:00 -0400 Original-Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1quAjt-00011p-Ee for emacs-devel@gnu.org; Sat, 21 Oct 2023 08:05:59 -0400 Original-Received: (qmail 97820 invoked by uid 3782); 21 Oct 2023 14:05:45 +0200 Original-Received: from acm.muc.de (pd953a465.dip0.t-ipconnect.de [217.83.164.101]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 21 Oct 2023 14:05:44 +0200 Original-Received: (qmail 16925 invoked by uid 1000); 21 Oct 2023 12:05:43 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:311649 Archived-At: Hello, Richard. On Sat, Oct 21, 2023 at 01:21:16 -0400, Richard Stallman wrote: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > Quite a lot of the function calls are things like cl-assert, cl-incf, or > > cl-defgeneric, which won't cause the loading of cl- until they are > > actually run. > Those are macros, right? These macros are not supposed to need cl-lib > at run time; they are supposed to be handled (when the code is > compiled) at compile time. A lot of them are macros, yes. When I filter out the macros from my list, and also functions of the form cl-generic-* and cl--generic-* (cl-generic is loaded at dump time), I'm left with these functions: * cl-call-next-method * cl--class-parents cl-member * cl-next-method-p cl-old-struct-compat-mode cl-plusp cl-print-object * cl--slot-descriptor-name * cl--slot-descriptor-props * cl--struct-class-children-sym * cl--struct-class-parents * cl--struct-register-child .. I've marked with an asterisk those that are in cl-preloaded.el or cl-generic.el. Of the remaining functions: (i) cl-member is used only in a compiler macro for add-to-list in subr.el. This is OK. (ii) cl-old-struct-compat-mode is called from cl-struct-define in cl-preloaded.el. It is an auto-load function which only gets loaded when cl-struct-define is called with an obsolete calling convention. (iii) cl-plusp is a defsubst, effectively a macro. (iv) cl-print-object is a defgeneric function in cl-print.el. There is a cl-defmethod of cl-print-object in nadvice.el. This contains calls to cl-print-object methods defined in cl-print.el Since cl-print-object is an auto-load, this should only cause cl-lib to get loaded at run time, not dump time. So it would appear there are no cl- functions used in the dumped .el files which would cause cl-lib to be loaded. There was only one cl- special variable which got bound to a non-nil value in the dumped .el files. That was cl--generic-edebug-name, defined and bound in cl-generic.el. It would take a more rigorous analysis to find any cl- variables bound to nil in these files. > Maybe people changed these macros and caused them to load cl-lib. > But maybe not all of them. I'm convinced this is not the case, unless it is by binding cl- special variables to nil. > I looked into cl-assert and found that it generates a call to > cl--assertion-failed, which is defined in xo cl-preloaded.el. > So I think that macro is ok -- the problem in question doesn't > seem to happen in cl-assert. > Which of the cl- macros really generate calls that require cl-lib > to be loaded? We should fix those. After scanning the source code, I'm convinced there aren't any, with the above proviso. > -- > Dr Richard Stallman (https://stallman.org) > Chief GNUisance of the GNU Project (https://gnu.org) > Founder, Free Software Foundation (https://fsf.org) > Internet Hall-of-Famer (https://internethalloffame.org) -- Alan Mackenzie (Nuremberg, Germany).