From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Lisp files that load cl-lib in problematical ways Date: Mon, 23 Oct 2023 14:18:01 +0300 Message-ID: <831qdlpoye.fsf@gnu.org> References: <87il8betof.fsf@dataswamp.org> <83fs3dgxv8.fsf@gnu.org> <835y38qvlg.fsf@gnu.org> <87bkcx6eci.fsf@dataswamp.org> <83ttqnm4ti.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36659"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 23 13:19:25 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 1qusxx-0009LX-1O for ged-emacs-devel@m.gmane-mx.org; Mon, 23 Oct 2023 13:19:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qusx7-00038m-Hb; Mon, 23 Oct 2023 07:18:33 -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 1qusx4-00038Q-J9 for emacs-devel@gnu.org; Mon, 23 Oct 2023 07:18:30 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qusx3-000115-0H; Mon, 23 Oct 2023 07:18:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=gIer6TUuf9FXwuqsWLWtc4I3Jqg3VcGA1UCnwtwtkCw=; b=QgtQaBNM1eSabhcqaUke d/4396lbs1Ka2xwttvJLQjAWaaPsNRxNQ4IlTa2LKI7NKcbzprVkeW8N11B/EveoH+3FQ6veueTYP 1g72i8wNP3l19kn+i+YCjt8uWrwUw0dUOhbcOA1GJNEtbbmNi1y1xrz4PWJT63bWcjrucMFGCdnUp F+0fnnI7LCr5U3JdCXxqV9Sn5elkbKxtlNxhAzEen60Rng3nKlk68hjYVs/g515akopkXAASODwfT F6giRxsHAw/5ss2C3y7tZb7j1mPYlg9j2zFZWxdPzndMamKiB0lJg8+aoFeKWsrKj/lt7hCQyp0Q4 YNt35aMOVhmj9g==; In-Reply-To: (message from Richard Stallman on Sun, 22 Oct 2023 22:08:55 -0400) 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:311702 Archived-At: > From: Richard Stallman > Cc: emacs-devel@gnu.org > Date: Sun, 22 Oct 2023 22:08:55 -0400 > > > abbrev.el:2 > > A generally useful minor mode as abbrev.el should not load cl-lib. > Why does it? I investigated. > > abbrev--check-chars uses the macro cl-pushnew. Generally we > arrange for cl- macros not to load cl-lib. But cl-pushnew > is _defined_ in cl-lib. It ought to be defined with and like > other cl- macros that are meant for users to use. It would not have helped to define cl-pushnew on cl-macs, because cl-pushnew calls cl-adjoin, which is a function defined on cl-lib. So basically cl-pushnew is a (rather thin) wrapper around cl-adjoin, and thus it is correctly defined on the same file where cl-adjoin is defined. I see no problem here. > I investigated byte-run.el. I don't think it uses any cl- facility. > Rather, it declares a let-variable whose name starts with cl-. byte-run.el indeed doesn't need cl-lib, and loading byte-run.elc doesn't load cl-lib. So I see no problem here, either. IOW, this is a false positive due to the naïve search pattern used to detect this. > I think that if we investigate the other general-purpose packages > in the list you posted (I copied it below), we wlll find many such bugs that > got in because developers were not on guard against them. I very much doubt that we will find many such bugs, because we actually pay close attention to these aspects as part of our patch review process. But, of course, there could be places we missed, so if someone finds them, please do report them and/or propose patches to fix them. > Once we fix them all, how about if we add a regression test > to verify that various packages anyone might load at any time > do not use cl-lib. With that, bugs like this would get caught > right away. It isn't easy to write such a test, since our test suite infrastructure, ert.el, itself uses cl-lib extensively. But if someone can come up with a test, please do submit it, and TIA.