unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: "Basil L. Contovounesios" <contovob@tcd.ie>,
	Michael Albinus <michael.albinus@gmx.de>
Cc: Glenn Morris <rgm@gnu.org>,  emacs-devel@gnu.org
Subject: Warning in tramp.el (was: Emacs is not reproducible)
Date: Sat, 05 Jun 2021 12:26:01 -0400	[thread overview]
Message-ID: <jwvfsxwxpfb.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87eedr44i0.fsf@tcd.ie> (Basil L. Contovounesios's message of "Fri, 28 May 2021 10:00:39 +0100")

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




  reply	other threads:[~2021-06-05 16:26 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-17 15:28 Emacs is not reproducible Bone Baboon
2021-05-17 15:45 ` Alan Mackenzie
2021-05-17 15:55   ` Achim Gratz
2021-05-17 15:54 ` Eli Zaretskii
2021-05-17 16:40 ` Stefan Monnier
2021-05-23  3:31   ` Stefan Monnier
2021-05-23 23:52     ` Glenn Morris
2021-05-25 17:41       ` Stefan Monnier
2021-05-25 17:52         ` T.V Raman
2021-05-25 18:03         ` Glenn Morris
2021-05-26 20:58           ` Stefan Monnier
2021-05-27 12:24             ` Mattias Engdegård
2021-05-27 21:33               ` Stefan Monnier
2021-05-25 18:27         ` Basil L. Contovounesios
2021-05-27 21:32           ` Stefan Monnier
2021-05-28  9:00             ` Basil L. Contovounesios
2021-06-05 16:26               ` Stefan Monnier [this message]
2021-06-06  6:42                 ` Warning in tramp.el Michael Albinus
2021-06-06 17:48                   ` Stefan Monnier

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=jwvfsxwxpfb.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=contovob@tcd.ie \
    --cc=emacs-devel@gnu.org \
    --cc=michael.albinus@gmx.de \
    --cc=rgm@gnu.org \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).