bug#50869: 28.0.50; tramp: void-function tramp-file-name-method--cmacro

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Hi Stefan,

> 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.

> In the men time, the `;;;###tramp-autoload` cookie placed before the
> `cl-defstruct` seems to trip over another bug when I try to build the
> package here:
>
>     Debugger entered--Lisp error: (scan-error "Containing expression ends 
> prematurely" 12345819 12345820)
>       scan-sexps(12345782 3)
>       forward-sexp(3)
>       autoload-print-form((defvar cl-struct-tramp-file-name-tags))
>     [...]
>
> Maybe it's a bug in the locally-hacked Emacs I'm using to do the build,
> tho.  Still, I suspect the cure might be not much better than the disease.

I extended tramp-test47-unload, which unloads / reloads Tramp. No error,
AFAICS. Feel free to fiddle with that test, in order to get it more
trustworthy in reproducing the problem.

>         Stefan

Best regards, Michael.