From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jens Schmidt via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#67005: 30.0.50; improve nadivce/comp/trampoline handling Date: Tue, 21 Nov 2023 23:10:52 +0100 Message-ID: <87bkbmiwpf.fsf@sappc2.fritz.box> References: <874jhv9921.fsf@sappc2.fritz.box> <875y24zrt1.fsf@sappc2.fritz.box> <87ttpmwuxi.fsf@sappc2.fritz.box> <877cmct4a1.fsf@sappc2.fritz.box> Reply-To: Jens Schmidt Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7224"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Cc: andrea corallo , 67005@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 21 23:13:07 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1r5YzQ-0001aH-JN for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 21 Nov 2023 23:13:04 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r5YyP-00077F-1d; Tue, 21 Nov 2023 17:12:01 -0500 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 1r5YyN-00076z-RZ for bug-gnu-emacs@gnu.org; Tue, 21 Nov 2023 17:11:59 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r5YyN-0001ja-JE for bug-gnu-emacs@gnu.org; Tue, 21 Nov 2023 17:11:59 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r5YyQ-0000No-2A for bug-gnu-emacs@gnu.org; Tue, 21 Nov 2023 17:12:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Jens Schmidt Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 21 Nov 2023 22:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67005 X-GNU-PR-Package: emacs Original-Received: via spool by 67005-submit@debbugs.gnu.org id=B67005.17006046791418 (code B ref 67005); Tue, 21 Nov 2023 22:12:02 +0000 Original-Received: (at 67005) by debbugs.gnu.org; 21 Nov 2023 22:11:19 +0000 Original-Received: from localhost ([127.0.0.1]:57592 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r5Yxi-0000Mo-Ua for submit@debbugs.gnu.org; Tue, 21 Nov 2023 17:11:19 -0500 Original-Received: from mr5.vodafonemail.de ([145.253.228.165]:37484) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r5Yxh-0000MX-00 for 67005@debbugs.gnu.org; Tue, 21 Nov 2023 17:11:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vodafonemail.de; s=vfde-mb-mr2-23sep; t=1700604668; bh=mJjWQ1hCuSwdf4ImBVspix1fA7JTOTVsCtTQLx66uVs=; h=From:To:Subject:References:Date:In-Reply-To:Message-ID:User-Agent: Content-Type:From; b=lT6JCcCszK3LvXJO+Y8fX2rVbn2lCBFsBEDEtXIEEczTBfL4B9XPkuq5P4MwXtuhE yW/d+tpDAQzrLMW+xg+CXTpx5rKTUPsbPmBLDXIe8XS+aDKynGFMLQAU6n0t6O8bvt fPb/go35VHg+FJKQsk6UHQoWWMDCBXrqMqVtKnJE= Original-Received: from smtp.vodafone.de (unknown [10.0.0.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mr5.vodafonemail.de (Postfix) with ESMTPS id 4SZdqv6wqWz1yJH; Tue, 21 Nov 2023 22:11:07 +0000 (UTC) Original-Received: from sappc2 (port-92-196-26-194.dynamic.as20676.net [92.196.26.194]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp.vodafone.de (Postfix) with ESMTPSA id 4SZdqj0h21zHnHf; Tue, 21 Nov 2023 22:10:53 +0000 (UTC) In-Reply-To: (Stefan Monnier's message of "Mon, 20 Nov 2023 22:35:55 -0500") X-purgate-type: clean X-purgate: clean X-purgate-size: 4119 X-purgate-ID: 155817::1700604663-FD7FF94E-DE9C42E8/0/0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:274742 Archived-At: Thanks, Stefan and Andrea, for your review. Stefan Monnier writes: >> (defcustom native-comp-never-optimize-functions >> - '(eval >> - ;; The following two are mandatory for Emacs to be working >> - ;; correctly (see comment in `advice--add-function'). DO NOT >> - ;; REMOVE. >> - macroexpand rename-buffer) >> + ;; Do not include functions `macroexpand' or `rename-buffer' as >> + ;; default values here. Despite the previous "DO NOT REMOVE" >> + ;; warnings these are no longer needed. See also the comment on >> + ;; `advice--add-function' and bug#67005. FIXME: But do include >> + ;; `eval' as temporary (?) remedy for bug#67141. >> + '(eval) >> "Primitive functions to exclude from trampoline optimization. > > I'm not sure I like the idea of keeping the whole history in comments. > I suggest you try and trim it down to the part that seems likely > to reoccur, like "We used to list those functions that were advised > during preload but we now prefer to disallow them in `advice-add`". Ok. Only slightly off-topic: When changing the default value of user option `native-comp-never-optimize-functions', which now both Andrea and I have done, does one also need to bump the :version? Or is this taken care of automagically? If it needs to be done manually, to which value should we/I set it? >> In `addvice--add-function' I wanted to at least preserve the comment >> from my initial patch (see attachment to >> https://yhetil.org/emacs-bugs/874jhv9921.fsf@sappc2.fritz.box/). I >> think it might help historical research if for that removal there is >> something that a "git blame" could be hooked onto. > > `C-x v h` is your friend. It was weird in the fist place to put the > trampoline stuff there (e.g. it's specific to functions stored in symbols so > it would have been more logical to put it into `advice-add` instead), so > it doesn't seem very likely that this will re-occur. Also Ok. `C-x v h` is my *new* friend. >> <<>>" >> + ;; Actively disallow function advices (here) and advices in general >> + ;; on primitives (in `comp--install-trampoline') during bootstrap >> + ;; for the following reasons: >> + ;; - Advices in Emacs' core are generally considered bad style. >> + ;; - `Snarf-documentation' looses docstrings of advised dumped >> + ;; functions (bug#66032#20). >> + ;; - Native compilation does not generate trampolines for advised >> + ;; primitives while loadup.el executes. > > I don't think this last point is true/relevant, is it? > IIUC it would use a "normal funcall", which doesn't need a trampoline. Yup, I got it messed up, again. BTW, it was this test in function `Fcomp__install_trampoline' which put me on the wrong track: /* FIXME: add a post dump load trampoline machinery to remove this check. */ if (will_dump_p ()) signal_error ("Trying to advice unexpected primitive before dumping", subr_name); I think during normal bootstrap this test should never fire, since this function never should be called, since its call is protected by `native-comp-enable-subr-trampolines'. >> ;; TODO: >> ;; - record the advice location, to display in describe-function. >> - ;; - change all defadvice in lisp/**/*.el. >> - ;; - obsolete advice.el. >> + (when purify-flag >> + (error "Invalid pre-dump advice on %s" symbol)) >> (let* ((f (symbol-function symbol)) >> >> What do you think? > > Beside the comments about the comments, it's a +1 from me. And here is another comment question: Do you think this snippet that made me so upset: (let* ((f (if (symbolp callee) (symbol-function callee) (cl-assert (byte-code-function-p callee)) callee)) (subrp (subrp f)) (comp-func-callee (comp-func-in-unit callee))) deserves some explanation? Along the lines of `subrp' not working as one might expect on advised primitives, which is exactly what we need here ... Will provide a new patch.