From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.bugs Subject: bug#58739: Lack of error message about number of args (?native compilation?) Date: Mon, 31 Oct 2022 13:15:18 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33051"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: 58739@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Oct 31 14:19:14 2022 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 1opUh8-0008Ne-4a for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 31 Oct 2022 14:19:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1opUeM-00015P-Sm; Mon, 31 Oct 2022 09:16:23 -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 1opUe5-0000f5-6t for bug-gnu-emacs@gnu.org; Mon, 31 Oct 2022 09:16:11 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1opUe2-0003qu-FV for bug-gnu-emacs@gnu.org; Mon, 31 Oct 2022 09:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1opUe1-0007ol-TZ for bug-gnu-emacs@gnu.org; Mon, 31 Oct 2022 09:16:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 31 Oct 2022 13:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58739 X-GNU-PR-Package: emacs Original-Received: via spool by 58739-submit@debbugs.gnu.org id=B58739.166722212526620 (code B ref 58739); Mon, 31 Oct 2022 13:16:01 +0000 Original-Received: (at 58739) by debbugs.gnu.org; 31 Oct 2022 13:15:25 +0000 Original-Received: from localhost ([127.0.0.1]:39764 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1opUdR-0006uA-9r for submit@debbugs.gnu.org; Mon, 31 Oct 2022 09:15:25 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:49594) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1opUdM-0006bd-0X for 58739@debbugs.gnu.org; Mon, 31 Oct 2022 09:15:23 -0400 Original-Received: from ma.sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 29VDFIKG020623 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 31 Oct 2022 13:15:18 GMT In-Reply-To: (Alan Mackenzie's message of "Sat, 29 Oct 2022 12:04:36 +0000") 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: , Original-Sender: "bug-gnu-emacs" Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:246682 Archived-At: Alan Mackenzie writes: > Hello, Andrea. > > On Tue, Oct 25, 2022 at 20:15:38 +0000, Andrea Corallo wrote: >> Alan Mackenzie writes: > >> > On Sun, Oct 23, 2022 at 12:12:49 +0000, Alan Mackenzie wrote: > > [ .... ] > >> >> As a matter of interest, I noticed this bug while byte-compiling >> >> desktop.el inside Emacs. It gave a warning message about the number of >> >> parameters to desktop-buffer having changed from 12+ to 12. > >> >> Here, I suspect there's a bug in the native compilation of >> >> desktop-buffer. > >> > The problem here is that (func-arity 'desktop-buffer) returns (12 . 12) on a >> > byte compiled desktop.elc, but (12 . many) on the corresponding .eln file. >> > This (12 . many) must be regarded as a bug, since there are no &rest >> > parameters in desktop-buffer. > >> > I propose a minor amendment to the definition of MANY, such that it will >> > mean "there are &rest parameters", rather than "the calling convention >> > is with nargs + *args". I have implemented this, and my patch is below. > >> > What I want to ask you to check is that in the native compiler, when >> > declare_imported_func encounters a function with, say, exactly 12 >> > arguments, it will throw an error. I think this is actually correct, >> > since the compiler cannot know whether this function uses the subr >> > calling convention of nargs + *args, or the byte coded convention of >> > pushing the 12 arguments individually onto the stack. Is throwing this >> > error a good idea? > >> Hi Alan, > >> to me this fix looks like a good idea (assuming changing the definition >> of MANY is acceptable). > > We'll see what Eli says. > >> I think also that throwing the error in 'declare_imported_func' is okay >> at this point. > > Apologies at this point. I should have produced an error from this > before bothering you. I was unable to produce such an error, and I've > spent the last few days understanding what happens here, with this > result: > > A call from a native compiled function is always in the form nargs + > *args, regardless of whether there are more than 8 arguments or not. > More accurately, the call to an unknown type of function (.eln/.elc/.el) > puts the function (in some form, I don't know exactly what) at element 0 > of *args, and the arguments themselves starting at element 1 of *args. > It then calls Ffuncall (or something like it). > > When the called function is a byte-code function, further down the call > stack exec_byte_code gets called with this (nargs + 1) + *args. > exec_byte_code then pushes the arguments onto the stack before > interpreting the byte code. > > So this "problem" with the native compiler not knowing what call sequence > to generate isn't a problem at all. It's all dealt with at run time. No > doubt this slows down Emacs quite a bit, but it's safe. > > So I'll take that bit out of my patch, and commit the rest of it to > master, and see what happens from there. Hi Alan, That's correct. As you prefer, we could also keep it as assertion. Thanks Andrea