Re: Warning in tramp.el

[Michael Albinus <michael.albinus@gmx.de>]

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

Hi Stefan,

> `tramp-handle-access-file` (in `tramp.el`) calls the inlinable
> `tramp-compat-file-missing` (from `tramp-compat.el`) which calls the
> inlinable `tramp-error` (from `tramp.el`).
>
> If `tramp-compat.el` is compiled first, we don't get any warning, but
> `tramp-error` is not inlined because `tramp-compat.el` doesn't require
> `tramp` (instead it `declare-function` on `tramp-error`).
> This case should arguably also signal a warning, because we fail to
> inline the function, and the only good fix for that would be to
> change the dependencies such that `tramp-compat.el` requires the file in
> which `tramp-error` is defined (which may require moving `tramp-error`
> to some other file to avoid circular dependencies).
>
> OTOH if `tramp-compat.el` is not yet compiled when we compile
> `tramp.el`, we get the above warning.  In that case, we *could* actually
> do the right thing and inline `tramp-error` (and the old inlining code
> got that right), but the info about `tramp-error` is kept inside
> `byte-compile-function-environment` at that point, and we don't pass
> that down to the recursive `byte-compile` (and to some extent for good
> reason: the inlined function should be compiled in "its" environment
> rather than in the environment of the caller).
>
> So we could try and fix this warning in the byte-compiler, but it
> could require non-trivial (or ugly) changes to the compiler.
>
> I think the better fix is to change the Tramp code to avoid this
> circular dependency.  This will not only avoid the warning but it will
> also make the inlining work in both cases (and avoid the need for
> `declare-function` here).

I've converted tramp-error from defsubst to defun. Unlike other Tramp
message functions, there's no reason for it to be a defsubst.

>         Stefan

Best regards, Michael.