bug#62004: 30.0.50; comp-run-async-workers failure when default-directory deleted

[No Wayman]

Eli Zaretskii <eliz@gnu.org> writes:

> Sorry, I don't think I understand.  Are you saying that we don't 
> bind
> default-directory to a safe value when compiling?

Correct. The default-directory is dependent on where 
comp-run-async-workers happens to kick off.
This can be reliably reproduced by:

1. saving the following elisp into test.el:

--8<---------------cut here---------------start------------->8---
;; -*- lexical-binding: t; -*-
(let* ((tempdir (expand-file-name "./temp/" user-emacs-directory))
      (default-directory tempdir)
      (feat 'org))
 ;; Ensure fresh test dir
 (when (file-exists-p tempdir) (delete-file tempdir))
 (make-directory tempdir)
 ;; Ensure test feature is not loaded.
 (when (featurep feat) (unload-feature feat t))
 (setq initial-buffer-choice
       (lambda ()
         (with-current-buffer (find-file (expand-file-name 
         "./temp.txt" tempdir))
           (insert "My directory will be deleted.")
           (write-file (expand-file-name "./temp.txt" tempdir))
           (delete-directory tempdir 'recursive)
           (message "default-directory: %S" default-directory)
           ;; comp-run-async-workers kicked off by JIT 
           compilation here.
           ;; This buffer has a file-name, but the directory no 
           longer exists.
           (require feat)
           (get-buffer-create (buffer-file-name))))))
--8<---------------cut here---------------end--------------->8---

2. launching emacs in a temporary init directory via:

> $ rm -rf /tmp/comp.test/ && emacs 
> --init-directory=/tmp/comp.test/ -l test.el

This should result in a *Messages* buffer similar to:

> For information about GNU Emacs and the GNU system, type C-h 
> C-a.
> (New file)
> Saving file /tmp/comp.test/temp/temp.txt...
> Wrote /tmp/comp.test/temp/temp.txt
> default-directory: "/tmp/comp.test/temp/"
> comp-run-async-workers: Setting current directory: No such file 
> or directory, /tmp/comp.test/temp/

>  IOW, how could a directory where the async compilation 
>  subprocess runs become invalid, in Real Life?

I ran into this error in the wild by:

- Installing a package to review it.
- Deleting the package's repository, but still had the package's 
 main elisp buffer open/current.
- Ran a command, which loaded a package, which kicked off the JIT 
 comp process.