From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Aaron Jensen 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 12:36:39 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35918"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46617@debbugs.gnu.org, 46617-done@debbugs.gnu.org To: Andrea Corallo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Mar 21 18:37:26 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 1lO210-0009FD-JQ for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 21 Mar 2021 18:37:26 +0100 Original-Received: from localhost ([::1]:34106 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lO20z-0001xx-Ct for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 21 Mar 2021 13:37:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40828) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lO20c-0001wn-UY for bug-gnu-emacs@gnu.org; Sun, 21 Mar 2021 13:37:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43868) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lO20c-0006Gy-NH for bug-gnu-emacs@gnu.org; Sun, 21 Mar 2021 13:37:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lO20c-0000re-Kp for bug-gnu-emacs@gnu.org; Sun, 21 Mar 2021 13:37:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Aaron Jensen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 21 Mar 2021 17:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46617 X-GNU-PR-Package: emacs Original-Received: via spool by 46617-done@debbugs.gnu.org id=D46617.16163482183303 (code D ref 46617); Sun, 21 Mar 2021 17:37:02 +0000 Original-Received: (at 46617-done) by debbugs.gnu.org; 21 Mar 2021 17:36:58 +0000 Original-Received: from localhost ([127.0.0.1]:55413 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lO20Y-0000r8-2Y for submit@debbugs.gnu.org; Sun, 21 Mar 2021 13:36:58 -0400 Original-Received: from mail-yb1-f172.google.com ([209.85.219.172]:39426) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lO20V-0000qq-Tc; Sun, 21 Mar 2021 13:36:56 -0400 Original-Received: by mail-yb1-f172.google.com with SMTP id z1so4085564ybf.6; Sun, 21 Mar 2021 10:36:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PCQoy+EPB+CDz4KjoiriQ7U1r8owFW2LcA6BOPZ7mn4=; b=OVkro6E2zrSv29iWkhLZI3darCGa7s2MjGzsVIxIo+aRkG8wdIjZEv1b9T/zQP6NkJ FaH5moexlCflzby6agt188EBTbQUHHKCcf2A/WPblb+8OqepKS0hE+WuLVb4Si5/dmUA PpTfuZ4amBjYA/sZwUCXP7B1JATQOnfRyQbIUIg+5FLZQPIBz0HL39VZe+8+1VDMVHF5 IODrYGnCPBpj6Vgq+aDqoriUQkhgJGi1s2fEUS9yERUJ7ju1D8UYVFHifoVyyljz4SiF 3cUd8hby60NRBRi3os8xEB5SFQmYr+Ja/z7EiBgeLgQDc3SEwYTML5UYeVoruVCSPPae WbdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PCQoy+EPB+CDz4KjoiriQ7U1r8owFW2LcA6BOPZ7mn4=; b=s0E+XhPx9LNd2R/FlJKbKJtX72FzYj0iF3QLMVaYbaopcn3Jaxhuyu9EVU/KiuEplq fjeg8IG9SMtVAHtHMJP9VvDVJHfM8tzUo6GCXtF35UtKj4hKlH08hyITc8rcERDmAZRB iSMwGTHCQcZx8cXM25Wtw2GG0sOM4GkOhgFpNe8IWdxVbK7QLAHd1q4G6URZLKZpFuZE uZU+i1ABCNRuo9RTwwv6l7p8LkqMyzkmivhc49+jkbArfy6NupoPWM9PS3c/4Y+fSH6V LGN6hJ1jhZj9F9dbgyJqdqw11zv+i6oXSjEGJ1SgzogekbVqv4JI+J5scY/EsL6jrRUI pq6Q== X-Gm-Message-State: AOAM530JtNw/SBpiwYfL9w6xGbL9k9Zf5gcxLIxUU1q1Va0ilflUNSDR 2gfE2zNXTlRoyDf4Pj/yVCwDoMdU2xF/tg7lT/I= X-Google-Smtp-Source: ABdhPJziN3/BWixkA2/fYAofFK37cdVUYFqDIQNaQteNMr3fZCEwrs2VIAxviBJXk37JI+cQaoxdPx1YRC4uWVH1OpU= X-Received: by 2002:a25:a226:: with SMTP id b35mr7793523ybi.275.1616348210415; Sun, 21 Mar 2021 10:36:50 -0700 (PDT) In-Reply-To: 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:202793 Archived-At: On Sun, Mar 21, 2021 at 12:27 PM Andrea Corallo wrote: > > Hi Aaron, > > I had to slightly modify your init.el reproducer as we have changed the > semantic of `load' [1]. With this change, how do you specify that you want the eln to load if it's there? If I understand correctly, this prevents loading the eln with load unless it is specified explicitly? Or can you leave the extension off when loading and that will prefer the eln, then elc, then el? > 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 original repro simulated a restart without a restart. The real bug (in straight.el) is that on start, it loads a byte compiled/native compiled file that relies on outside environment. So, that may be fixed now because I believe they load the elc explicitly, but that means it'll never load the native compiled version. Ideally, they would, but I don't know how to force loading byte compiled OR native compiled in one command. > 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? I think it sounds like straight.el will need to add detection for native compilation, and any time they byte compile, also native compile. I also think that this is extremely fragile and I wonder if byte compiling should result in "invalidating" (deleting) the previously corresponding eln. We essentially have a cache invalidation that is relying purely on a cache key that is incomplete. Thanks, Aaron