all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: shuguang79@qq.com, 50869@debbugs.gnu.org
Subject: bug#50869: 28.0.50; tramp: void-function tramp-file-name-method--cmacro
Date: Fri, 02 Sep 2022 14:52:27 -0400	[thread overview]
Message-ID: <jwvczcd4ohz.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87pmlydvd4.fsf@gmx.de> (Michael Albinus's message of "Sun, 03 Apr 2022 17:44:55 +0200")

[-- Attachment #1: Type: text/plain, Size: 2180 bytes --]

Michael Albinus [2022-04-03 17:44:55] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Note: this is not a compile error.  It's an error that happened during
>> expansion of a compiler-macro.  These are optional, so those errors only
>> affect the performance of the code but shouldn't affect its behavior.
>>
>> IOW this sound more serious than it is.
>>
>> `tramp-file-name-method--cmacro` is supposed to be a function which
>> inlines the code of calls to `tramp-file-name-method`.
>>
>> More specifically `tramp-file-name-method--cmacro` is auto-generated
>> (and put on the `compiler-macro` property of the
>> `tramp-file-name-method` symbol) by the `cl-defsubst` used to define
>> `tramp-file-name-method`.
>>
>> So I guess the source of the error is that unloading `tramp` undefines
>> the functions (both `tramp-file-name-method--cmacro` and
>> `tramp-file-name-method`) but leaves the `compiler-macro` property of the
>> `tramp-file-name-method` symbol.
>>
>> We really should make it so package unloading knows how to undo
>> top-level `put`s.
>
> Honestly, I have no knowledge about the byte-compiler. I've reopened the
> bug, so you can work on it.

The main point is that putting the `cl-defstruct` into the
`tramp-loaddefs.el` is really ugly and I think it's asking for trouble.
In contrast the OP's "errors" aren't actual errors, they're just
messages indicating that some optimization could not be applied.
We should really change the wording to clarify that they're warnings.

(see first hunk in patch below).

But in the mean time I'd much rather live with a harmless
"compiler-macro error" message than with a `cl-defstruct` in
a loaddefs file.

Lars Ingebrigtsen [2022-09-02 13:43:48] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> We really should make it so package unloading knows how to undo
>> top-level `put`s.
> Do you have any ideas for how to do that?

There are a few ways:
- We could let `unload-feature` remove compiler macros when present, as
  in the second hunk of the patch below.
- We could make `cl-defstruct` use `define-symbol-prop` rather than
  `put`, as in the third hunk of the patch below.


        Stefan

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: comp-macro.patch --]
[-- Type: text/x-diff, Size: 1629 bytes --]

diff --git a/lisp/emacs-lisp/macroexp.el b/lisp/emacs-lisp/macroexp.el
index c3ba1b36d44..f4df40249de 100644
--- a/lisp/emacs-lisp/macroexp.el
+++ b/lisp/emacs-lisp/macroexp.el
@@ -110,7 +110,8 @@ macroexp--compiler-macro
       (let ((symbols-with-pos-enabled t))
         (apply handler form (cdr form)))
     (error
-     (message "Compiler-macro error for %S: Handler: %S\n%S" (car form) handler err)
+     (message "Warning: Optimization failure for %S: Handler: %S\n%S"
+              (car form) handler err)
      form)))
 
 (defun macroexp--funcall-if-compiled (_form)
diff --git a/lisp/loadhist.el b/lisp/loadhist.el
index b4ed0432465..76da002314b 100644
--- a/lisp/loadhist.el
+++ b/lisp/loadhist.el
@@ -171,6 +171,8 @@ loadhist-unload-element
     (cond
      ((null hist)
       (defalias fun nil)
+      (if (get fun 'compiler-macro) (put fun 'compiler-macro nil))
+      (if (get fun 'gv-expander)    (put fun 'gv-expander nil))
       ;; Override the change that `defalias' just recorded.
       (put fun 'function-history nil))
      ((equal (car hist) loadhist-unload-filename)
diff --git a/lisp/emacs-lisp/cl-macs.el b/lisp/emacs-lisp/cl-macs.el
index 80ca43c902a..b7fee7a3487 100644
--- a/lisp/emacs-lisp/cl-macs.el
+++ b/lisp/emacs-lisp/cl-macs.el
@@ -3570,7 +3570,7 @@ cl-define-compiler-macro
        (cl-defun ,fname ,(if (memq '&whole args) (delq '&whole args)
                            (cons '_cl-whole-arg args))
          ,@body)
-       (put ',func 'compiler-macro #',fname))))
+       (define-symbol-prop ',func 'compiler-macro #',fname))))
 
 ;;;###autoload
 (defun cl-compiler-macroexpand (form)

  reply	other threads:[~2022-09-02 18:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-28 15:15 bug#50869: 28.0.50; tramp: void-function tramp-file-name-method--cmacro Shuguang Sun via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-10-02 16:36 ` Michael Albinus
2022-03-17 14:39   ` Michael Albinus
2022-04-02 21:09   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-03 15:44     ` Michael Albinus
2022-09-02 18:52       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2022-09-03 10:07         ` Lars Ingebrigtsen
2022-09-03 19:08           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-09-04 14:53             ` Michael Albinus
2022-09-04 16:44               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-09-04 17:27                 ` Michael Albinus
2022-09-04 18:03                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-09-02 11:43     ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvczcd4ohz.fsf-monnier+emacs@gnu.org \
    --to=bug-gnu-emacs@gnu.org \
    --cc=50869@debbugs.gnu.org \
    --cc=michael.albinus@gmx.de \
    --cc=monnier@iro.umontreal.ca \
    --cc=shuguang79@qq.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.