From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Warning in tramp.el (was: Emacs is not reproducible) Date: Sat, 05 Jun 2021 12:26:01 -0400 Message-ID: References: <87lf8dcrcd.fsf@disroot.org> <15pmxh100n.fsf@fencepost.gnu.org> <87r1huwtwz.fsf@tcd.ie> <87eedr44i0.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="541"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Glenn Morris , emacs-devel@gnu.org To: "Basil L. Contovounesios" , Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 05 18:27:14 2021 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 1lpZ8e-000AIv-Jn for ged-emacs-devel@m.gmane-mx.org; Sat, 05 Jun 2021 18:27:13 +0200 Original-Received: from localhost ([::1]:59110 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lpZ8d-00083L-H4 for ged-emacs-devel@m.gmane-mx.org; Sat, 05 Jun 2021 12:27:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47982) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lpZ7x-0007Im-Um for emacs-devel@gnu.org; Sat, 05 Jun 2021 12:26:25 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:60614) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lpZ7u-0006dg-DM; Sat, 05 Jun 2021 12:26:24 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9563C4411E0; Sat, 5 Jun 2021 12:26:16 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BB7304409B1; Sat, 5 Jun 2021 12:26:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1622910367; bh=Icee9sF/pLZp2kboLYeN57cRj9ewd4KXcU7i7OeISA0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=CtvVAFZ6ExExrx57xPOm0Iuq33YCY43XXo9WFGImD0OJMGq4+6kFqXRIEWMozlh7H A/WbMBVbk8C6w/YAA018ErZ6wXMVdLJx98VHNkDIixRkwHKbIHX0Me9MbEL4ZTRtI2 CXH1HO3PALtHy0EfdUkeHnwXvneUrNveZREAAlHcO5UILc1l8juammHJbePw4satDR Gwk9aEaTl6+YPKHJlWLBwOTxab4RezxFUPmhsHi40qGaQbO7kMMnkCfGutzBFG2g37 Rgg49GS0tbcWgiqV9EwQefMnaui8K7r/sk8EAoPg3k8cs2K6OXAuJbdKmtRd548MNh s+e/lqQxF4Qig== Original-Received: from alfajor (69-196-163-239.dsl.teksavvy.com [69.196.163.239]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7FA1A120284; Sat, 5 Jun 2021 12:26:07 -0400 (EDT) In-Reply-To: <87eedr44i0.fsf@tcd.ie> (Basil L. Contovounesios's message of "Fri, 28 May 2021 10:00:39 +0100") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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.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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:270440 Archived-At: Basil L. Contovounesios [2021-05-28 10:00:39] wrote: > Stefan Monnier writes: >>> FYI if those test failures prove too boring there are some new and >>> exciting bootstrap warnings to play with too :). >>> >>> In end of data: >>> calc/calc.el:3126:27: Warning: the function =E2=80=98math-compare=E2=80= =99 is not known to be >>> defined. >>> calc/calc.el:2805:27: Warning: the function =E2=80=98math-zerop=E2=80= =99 is not known to be >>> defined. >>> In tramp-handle-access-file: >>> net/tramp.el:3238:43: Warning: attempt to inline =E2=80=98tramp-error= =E2=80=99 before it was >>> defined >>> net/tramp.el:3238:43: Warning: attempt to inline =E2=80=98tramp-error= =E2=80=99 before it was >>> defined >> >> I believe these should be fixed now. > > All but the tramp-error one (at least with sufficiently parallel > bootstrap)! This one is a bit more tricky: `tramp-handle-access-file` (in `tramp.el`) calls the inlinable `tramp-compat-file-missing` (from `tramp-compat.el`) which calls the inlinable `tramp-error` (from `tramp.el`). If `tramp-compat.el` is compiled first, we don't get any warning, but `tramp-error` is not inlined because `tramp-compat.el` doesn't require `tramp` (instead it `declare-function` on `tramp-error`). This case should arguably also signal a warning, because we fail to inline the function, and the only good fix for that would be to change the dependencies such that `tramp-compat.el` requires the file in which `tramp-error` is defined (which may require moving `tramp-error` to some other file to avoid circular dependencies). OTOH if `tramp-compat.el` is not yet compiled when we compile `tramp.el`, we get the above warning. In that case, we *could* actually do the right thing and inline `tramp-error` (and the old inlining code got that right), but the info about `tramp-error` is kept inside `byte-compile-function-environment` at that point, and we don't pass that down to the recursive `byte-compile` (and to some extent for good reason: the inlined function should be compiled in "its" environment rather than in the environment of the caller). So we could try and fix this warning in the byte-compiler, but it could require non-trivial (or ugly) changes to the compiler. I think the better fix is to change the Tramp code to avoid this circular dependency. This will not only avoid the warning but it will also make the inlining work in both cases (and avoid the need for `declare-function` here). Stefan