Warning in tramp.el (was: Emacs is not reproducible)

[Stefan Monnier]

Basil L. Contovounesios [2021-05-28 10:00:39] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> FYI if those test failures prove too boring there are some new and
>>> exciting bootstrap warnings to play with too :).
>>>
>>> In end of data:
>>> calc/calc.el:3126:27: Warning: the function ‘math-compare’ is not known to 
>>> be
>>>     defined.
>>> calc/calc.el:2805:27: Warning: the function ‘math-zerop’ is not known to be
>>>     defined.
>>> In tramp-handle-access-file:
>>> net/tramp.el:3238:43: Warning: attempt to inline ‘tramp-error’ before it was
>>>     defined
>>> net/tramp.el:3238:43: Warning: attempt to inline ‘tramp-error’ before it was
>>>     defined
>>
>> I believe these should be fixed now.
>
> All but the tramp-error one (at least with sufficiently parallel
> bootstrap)!

This one is a bit more tricky:

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


        Stefan