GNU bug report logs - #41065
Result of byte-compilation can be nil even if the compiled file contains no errors

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Pogonyshev <pogonyshev <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Result of byte-compilation can be nil even if the compiled file
 contains no errors
Date: Mon, 4 May 2020 00:21:02 +0200

[Message part 1 (text/plain, inline)]

To reproduce, save this as file `main.el':

    (eval-when-compile
      (let ((default-directory (expand-file-name "/tmp/myprivatelib/")))
        (make-directory default-directory t)
        (with-temp-file "thelib.el"
          (insert "(defun im-a-library-function ()\n"
                  "  (trigger-a-warning-here-1))\n"
                  "(provide 'thelib\n"))  ; <- intentionally erroneous
syntax
        (byte-compile-file "thelib.el")))

    (defun blabla ()
      (trigger-a-warning-here-2))

and execute:

    $ emacs --batch --eval "(print (byte-compile-file \"main.el\"))"

Result is:

    In toplevel form:
    thelib.el:3:1: Error: End of file during parsing

    In end of data:
    ~/test/nested-compilation/main.el:12:1: Warning: the function
        ‘trigger-a-warning-here-2’ is not known to be defined.

    nil

The last line is the result of the call to `byte-compile-file'
from the command line and it is nil.  But this is wrong, because
`main.el' is syntactically correct and never triggers an error:
you can verify this by evaluating `let' form manually.  What
failed is the "inner" compilation, but it must not affect the
result of the "main" compilation process.

A smaller problem is that the path to `main.el' is written fully,
because it is apparently found from `/tmp/myprivatelib', which
further corroborates my guess that the two byte-compilation
processes are improperly lumped together.

If you fix generated `thelib.el' by adding the missing paren,
"outer" compilation will succeed.

I emailed this to to `emacs-devel' quite a while ago:

    https://lists.gnu.org/archive/html/emacs-devel/2020-02/msg00227.html

and the answer from Stefan Monnier confirmed that this should be
qualified as a bug.  I have forgotten to resubmit this to
`bug-gnu-emacs' until now.

Paul

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.