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: Re: More reliable byte compilation, take 45 Date: Mon, 04 Oct 2021 16:13:33 -0400 Message-ID: References: <87sfxhm5aw.fsf@gnus.org> <9bffb61b-c948-c431-4fb0-bbc74e91dfe2@gmail.com> <837des6479.fsf@gnu.org> <831r506025.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2909"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: raman@google.com, cpitclaudel@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 04 22:20:59 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 1mXUSI-0000XU-PW for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Oct 2021 22:20:58 +0200 Original-Received: from localhost ([::1]:59576 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mXUSG-0006Ig-SE for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Oct 2021 16:20:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44456) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mXULz-00079D-5q for emacs-devel@gnu.org; Mon, 04 Oct 2021 16:14:27 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:49374) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mXULv-0000mf-Ud; Mon, 04 Oct 2021 16:14:26 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A2BAC440485; Mon, 4 Oct 2021 16:14:21 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3EF8C4404E1; Mon, 4 Oct 2021 16:14:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1633378460; bh=XoPMVg+1Yyd52+cAeKKIQN0g4qJ0fOpm84useYT04w0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=RrzV8iMy9sFVbBjJ8tQpuvoD7dlr6ds9fKYSM2Mgh2sCcKQgoMrHfwqqnk2xZXpC2 CkXR0+fWjXO2gh0WK2FlLPzJqsuwUwN/myR3/CFrA06AEoOQeTnmkk05dfjq16TB47 tKFgz01HvRE55iQKJwuOn+auBHH24DWropxPxhDiCi2QIrw7rSfGScsr9Rcrv2inC8 uVj2tP6RxEKn2avorp6Y1YrLZMG+LxeMRqGVfXEgVl/wIoKsxNSEeO+CrFUEqZnDdX BxBZNJFK1AZbXP1ICJrQXn/WKFz2DI1xjNp6yt9/JdV80hzSQq7UMhm1Fhc8qszPkQ Y44rKG2eIzjKg== Original-Received: from alfajor (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2B37B120483; Mon, 4 Oct 2021 16:14:20 -0400 (EDT) In-Reply-To: <831r506025.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 04 Oct 2021 22:51:14 +0300") 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:276267 Archived-At: >> Converting a `.elc` file to a `.eln` file can be done by a pure function >> with no need for any extra information. > I very much doubt that. You might be right, there might be corner cases I'm not taking into account, but by and large it should be the case. At least much more so than for `.el` files where it's clearly a real problem. > I have no reason to believe that the problems we see with native > compilation are related to these aspects. I'm not sure which problems you're referring to. Within the context of Emacs's own ELisp files, this should never be an issue. > Do you have evidence of that? IIRC, in Raman's case the evidence was that the `.eln` file was calling a macro as if it were a function, and that this didn't happen when using the `.elc` file. These problems typically happen when a `.el` file is miscompiled because some other ELisp file was not loaded beforehand. Admittedly, I don't have actual evidence, but it seemed to hint at that. In any case, the problem with compiling from the `.el` file instead of from the `.elc` file is real and it's easy to trigger it on purpose. The only question for me is how often it will bite us out there in the real world. There's a chance that it will simply encourage people to fix their ELisp files to better follow the (undocumented) conventions, so to some degree I agree that it might be preferable not to fix this issue. Stefan