From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: Towards a cleaner build Date: Sun, 09 Jun 2019 18:24:52 +0200 Message-ID: References: <83zhn6zkgf.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="126568"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Eli Zaretskii , Stefan Monnier , Emacs developers To: Noam Postavsky Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 09 18:25:11 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ha0d4-000Wme-GQ for ged-emacs-devel@m.gmane.org; Sun, 09 Jun 2019 18:25:10 +0200 Original-Received: from localhost ([::1]:36974 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1ha0d2-0006Y9-SY for ged-emacs-devel@m.gmane.org; Sun, 09 Jun 2019 12:25:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51098) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1ha0cx-0006Xp-AB for emacs-devel@gnu.org; Sun, 09 Jun 2019 12:25:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ha0cw-0007mD-6A for emacs-devel@gnu.org; Sun, 09 Jun 2019 12:25:03 -0400 Original-Received: from quimby.gnus.org ([80.91.231.51]:40214) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ha0cv-0007ke-WE; Sun, 09 Jun 2019 12:25:02 -0400 Original-Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=stories) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ha0cm-0004hs-Q5; Sun, 09 Jun 2019 18:24:56 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAD1BMVEVBPj+Qjo8cGhvk4+Rd W1wEEOLaAAACbElEQVQ4jVVUi5XjIAyUWQpAgQKwzgWExQVIRP3XdCPbu/eOOHkvmugzMyJEax3W tXNtzDNt2k2S7JXykj2J7zwnnpVTrgCs0raWLbH+qYhP2pQrkThTFeHVc7cAhuxv5tykN9JXVj9I ckXCmezFNfMyprcs0SNJvwEt2aR7ZSqyuqmmbqiEKZZ06VtttMRJ89oVLd6kW+oJ024EoJgWOZzr PMnZ26ukowm9+iJvObPzHGRK3ExRLoCuG5sexsMRrXNYkgAkvUWkp4z297kBBFPZIQ15veMDocjI 2gkqSHYLZAy7AelWnDpmzl7HnOW7pAtImNGqq6OWMXPqlAMoRAYnXDOy3K2JSnmAT8OIroRX3kZa PYai7+7IB1K8ZN80xALQ6U05kFEHx2mb08UKADrWMcKmUWczRzMMRKfxxBbwQ7oym3vKmYpxPX84 34fdsxHauPmTwHx/og86EfOHR0QasuflcA+NZJxmLaSNMJ7hQRDvNqjRJfq4VAyGCboqxmj+0wat g0WioI0wQLAEQWNdaSnBYtBzhYHYA8wId1d/odQMoTwcULkM+vBqMdVEPtYN7eQ+B9NGAUxeEuq1 nVuBNa+eQmDiSGmefHU3ze4FvwlgxIUZNXYsTqcPuioW7qJ1nphHDzBQgWeMOejSesBz6f2riezz 6ip0qTaqE7X01dL1faRfIJSGPXzr3uQpFYimf3rx/0Bq4f5vxteDwLTtic8Wzcdj9wm6/JS6NvHa j8Hh2vEk3NfgAkBkh7z+586IO0PjGvE8Nmh1sYsewQNG8SgM1p7liIWss6IubVntHSapZBWKP4h3 Ra2/KpGfrnT/8xAAAAAASUVORK5CYII= In-Reply-To: (Noam Postavsky's message of "Sun, 9 Jun 2019 12:15:47 -0400") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 80.91.231.51 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:237351 Archived-At: Noam Postavsky writes: > On Sun, 9 Jun 2019 at 11:40, Lars Ingebrigtsen wrote: > >> (with-suppressed-warnings ((lexical prefixless)) >> (defvar prefixless)) > > It's a bit funny that the warning is named 'lexical', when it's about > a non-lexical variable. > >> (with-suppressed-warnings ((obsolete obsolete)) >> (obsolete)) > >> (with-suppressed-warnings ((obsolete obsolete-variable)) >> obsolete-variable) > > We might want to support suppressing the warning for obsolete > functions and variables separately? > >> (with-suppressed-warnings ((mapcar mapcar)) >> (mapcar #'list '(1 2 3))) > > This is the 'mapcar called for effect' one, right? Could we group it > with 'value returned from (+ 1 2) is unused' for (progn (+ 1 2) nil)? > Even though the byte compiler implementation might have them seperate, > I think they're pretty much the same thing from the point of view of > an elisp author. I agree with all these, but I thought it might be nice to have the same symbols as in byte-compile-warnings (and byte-compile-warning-types), which are: => (redefine callargs free-vars unresolved obsolete noruntime cl-functions interactive-only make-local mapcar constants suspicious lexical) If we diverge featurewise between `byte-compile-warnings' and `with-suppressed-warnings', I think that will be confusing. But... perhaps we could tweak `byte-compile-warnings' featurewise, too? That is, split `obsolete' into `obsolete-function' and `obsolete-variable' (and retain `obsolete' as a catch-all for both), etc... Perhaps that'd be nice? `effect' would then be the new synonym for `mapcar'... And we could have `no-prefix' as a synonym for `lexical'. Actually, I'd guess that `lexical' was chosen because you only get that warning in files with lexical binding, but it's kinda opaque that it has that effect. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no