bug#68083: 30.0.50; Intermittent build failure with native compilation

[Eli Zaretskii <eliz@gnu.org>]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sat, 30 Dec 2023 10:29:16 -0500
> Cc: acorallo@gnu.org, 68083@debbugs.gnu.org, jschmidt4gnu@vodafonemail.de
> 
> On Sat, Dec 30, 2023 at 1:47 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > Are you sure?  We do that on Windows because Windows doesn't allow us
> > to delete a file that is open by another program.  That shouldn't
> > happen on Posix systems, so I think what you see here is due to a race
> > between checking whether a file exists and renaming it, which is a
> > different problem.
> >
> > However, feel free to try the same trick we use on Windows and see
> > whether it helps.
> 
> This fixes it for me:
> 
> diff --git a/lisp/emacs-lisp/comp.el b/lisp/emacs-lisp/comp.el
> index 3b2fd25e61c..80088f935a4 100644
> --- a/lisp/emacs-lisp/comp.el
> +++ b/lisp/emacs-lisp/comp.el
> @@ -3341,7 +3341,11 @@ comp-delete-or-replace-file
>          ;; is currently loaded.
>          (t (delete-file oldfile)
>             (when newfile
> -             (rename-file newfile oldfile)))))
> +             (condition-case _
> +                 (rename-file newfile oldfile)
> +               (file-already-exists
> +                (delete-file newfile)
> +                t))))))

What happens if, instead of wrapping rename-file in condition-case,
you change that to say

  (t (if newfile
	 (rename-file newfile oldfile)
       (delete-file oldfile))

> I imagine that this is worth doing just to make this operation
> parallel-safe, but I wonder why macroexpand is the only instance of
> this happening. I don't know if macroexpand should still be in
> native-comp-never-optimize-functions or not (i.e., is there another
> reason it was there other than to avoid this crash?)

rename-file is supposed to be an atomic operation on Posix
filesystems, so I don't quite understand why you see what you see, and
I'm hesitant to sweep under the carpet a problem we don't understand.