From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#46617: 28.0.50; nativecomp: native compile cache is not invalidated when file is re-byte compiled and changes Date: Sun, 21 Mar 2021 17:27:30 +0000 Message-ID: References: Reply-To: Andrea Corallo Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36765"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 46617@debbugs.gnu.org, 46617-done@debbugs.gnu.org To: Aaron Jensen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Mar 21 18:28:13 2021 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 1lO1s5-0009Rx-JK for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 21 Mar 2021 18:28:13 +0100 Original-Received: from localhost ([::1]:56072 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lO1s4-0006pA-K4 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 21 Mar 2021 13:28:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34082) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lO1rv-0006lM-6y for bug-gnu-emacs@gnu.org; Sun, 21 Mar 2021 13:28:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43848) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lO1ru-0001Xa-Vr for bug-gnu-emacs@gnu.org; Sun, 21 Mar 2021 13:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lO1ru-0000cJ-SK for bug-gnu-emacs@gnu.org; Sun, 21 Mar 2021 13:28:02 -0400 Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Sun, 21 Mar 2021 17:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 46617 X-GNU-PR-Package: emacs Mail-Followup-To: 46617@debbugs.gnu.org, akrl@sdf.org, aaronjensen@gmail.com Original-Received: via spool by 46617-done@debbugs.gnu.org id=D46617.16163476562324 (code D ref 46617); Sun, 21 Mar 2021 17:28:02 +0000 Original-Received: (at 46617-done) by debbugs.gnu.org; 21 Mar 2021 17:27:36 +0000 Original-Received: from localhost ([127.0.0.1]:55390 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lO1rU-0000bL-9P for submit@debbugs.gnu.org; Sun, 21 Mar 2021 13:27:36 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:64518) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lO1rP-0000b5-Va; Sun, 21 Mar 2021 13:27:34 -0400 Original-Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 12LHRUsS025644 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sun, 21 Mar 2021 17:27:31 GMT In-Reply-To: (Aaron Jensen's message of "Thu, 25 Feb 2021 10:09:08 -0600") 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" Xref: news.gmane.io gmane.emacs.bugs:202791 Archived-At: Aaron Jensen writes: > On Thu, Feb 25, 2021 at 3:04 AM Andrea Corallo wrote: >> >> Even tho I've no precise analysis on this most likely this is related to >> the fact that I broke async compilation with 81b1013555 and fixed it >> with 0ee1a16769. >> >> Right I'm closing this (we can always reopen in case). > > Ah, I'm afraid we have to reopen. What you describe was the reason it > didn't repro for me this last time. It still does currently. Hi Aaron, I had to slightly modify your init.el reproducer as we have changed the semantic of `load' [1]. init.el: ========= (let ((repro (expand-file-name "repro.el" default-directory))) (defun some-fn () 1) (message "Byte and native compiling, some-fn = 1") (byte-compile-file repro) (load (native-compile repro)) (message "Byte compiling, some-fn = 2") (defun some-fn () 2) (byte-compile-file repro) (load (concat repro "c") nil 'nomessage 'nosuffix) (message "Native compiling, some-fn = 2") (load (native-compile repro))) ========= This is still: - defining `some-fn' - native compiling and loading repro.el - re-defining `some-fn' - byte compiling and loading repro.el - native compiling and loading repro.el Running ./src/emacs -Q -l init.el in the *Messages* buffer I get: ========= Byte and native compiling, some-fn = 1 Compiling /home/andcor03/emacs2/repro.el...done Wrote /home/andcor03/emacs2/repro.elc Compiling /home/andcor03/emacs2/repro.el...done Loading /home/andcor03/.emacs.d/eln-cache/28.0.50-32137a9a/repro-fd364f11-b5afb0b4.eln (native compiled elisp)... EQUAL Loading /home/andcor03/.emacs.d/eln-cache/28.0.50-32137a9a/repro-fd364f11-b5afb0b4.eln (native compiled elisp)...done Byte compiling, some-fn = 2 Compiling /home/andcor03/emacs2/repro.el...done Wrote /home/andcor03/emacs2/repro.elc EQUAL Native compiling, some-fn = 2 Compiling /home/andcor03/emacs2/repro.el...done Loading /home/andcor03/.emacs.d/eln-cache/28.0.50-32137a9a/repro-fd364f11-b5afb0b4.eln (native compiled elisp)... EQUAL Loading /home/andcor03/.emacs.d/eln-cache/28.0.50-32137a9a/repro-fd364f11-b5afb0b4.eln (native compiled elisp)...done ========= I think what happened is that in the original reproducer the second load of the .elc file still automatically loaded in place the corresponding .eln as the source file didn't changed. The issue here is that in the compilation unit repro.elk is capturing some of the environment and this is not accounted in the hash computation of the .eln file. The new reproducer (well it does not reproduce much :) ) works because now `load' called explicitly on a .elc file does not load automatically the corresponding .eln. Alternatively to overcome the issue still using native compilation one has to force a new native compilation using `native-compile. WDYT? Thanks Andrea [1]