bug#12548: 24.2.50; Eager macro-expansion skipped due to cycle

bug#12548: 24.2.50; Eager macro-expansion skipped due to cycle

[Eli Zaretskii]

This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org.  Please check that
the From: line contains a valid email address.  After a delay of up
to one day, you should receive an acknowledgment at that address.

Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug.  If you can, give a recipe
starting from `emacs -Q':

The recipe is:

  configure
  make bootstrap

Since about 2 weeks ago, I see these warning messages while
bootstrapping on MS-Windows, when Lisp files are being byte-compiled.
Two typical examples:

  Warning: Eager macro-expansion skipped due to cycle:
    Γאª => (load "erc-backend.el") => (macroexpand-all (defun erc-server-connect Γאª)) => (macroexpand (erc-log Γאª)) => (load "erc.el") => (load "erc-backend.el")
  Wrote d:/gnu/bzr/emacs/test2/lisp/erc/erc-autoaway.elc

  Warning: Eager macro-expansion skipped due to cycle:
    Γאª => (load "tramp.el") => (macroexpand-all (defun tramp-action-login Γאª)) => (macroexpand (with-connection-property Γאª)) => (load "tramp-cache.el") => (load "tramp.el")
  Wrote d:/gnu/bzr/emacs/test2/lisp/eshell/esh-module.elc

(I don't know what is that binary garbage, maybe some byte code.)

AFAICS, all of these messages are related either to loading tramp.el
or erc-backend.el.  But I may have missed others, not sure.

Please remember that byte compilation during bootstrap on Windows is
done with an Emacs binary dumped with .el version of the byte compiler
and its subroutines.  I never saw anything similar in "regular" byte
compilation after updating from the master repository, FWIW.

If I can give more information about this, please ask.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
d:/gnu/bzr/emacs/trunk/etc/DEBUG.


In GNU Emacs 24.2.50.1 (i386-mingw-nt5.1.2600)
 of 2012-10-01 on HOME-C4E4A596F7
Bzr revision: 110321 rgm@gnu.org-20121001102100-dz558kg6c659l9f6
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (3.4) --no-opt --enable-checking --cflags
 -Id:/usr/include/libxml2 -DGLYPH_DEBUG=1'

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x r e p o r t - e m <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win w32-vars
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process multi-tty emacs)

bug#12548: 24.2.50; Eager macro-expansion skipped due to cycle

[Stefan Monnier]

> Since about 2 weeks ago, I see these warning messages while
> bootstrapping on MS-Windows, when Lisp files are being byte-compiled.

Hmm.. you should have seen them since when I introduced the
eager-macroexpansion, which is a bit more than 2 weeks.

>   Warning: Eager macro-expansion skipped due to cycle:
>     Γאª => (load "erc-backend.el") => (macroexpand-all (defun erc-server-connect Γאª)) => (macroexpand (erc-log Γאª)) => (load "erc.el") => (load "erc-backend.el")

[ Not sure what this Γאª is about, but I'll assume it's some incorrect
  encoding of … ]

> AFAICS, all of these messages are related either to loading tramp.el
> or erc-backend.el.  But I may have missed others, not sure.

Yes, IIRC there are two such problematic cycles, one with Tramp and
another with ERC (there were a couple more, but I fixed them).
I'm not completely sure how best to fix them, so I preferred to leave
them in and wait for the ERC and Tramp maintainers to fix them later.
They're harmless in the sense that the resulting .elc files should be
correct (and probably even identical).

I think the warning prints a clear and concise description of the cycle,
so it should not be too hard for the maintainers of those packages to
understand the problem and decide how best to fix it.

> and its subroutines.  I never saw anything similar in "regular" byte
> compilation after updating from the master repository, FWIW.

A bootstrap under GNU/Linux shows those same warnings.


        Stefan

bug#12548: 24.2.50; Eager macro-expansion skipped due to cycle

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 12548@debbugs.gnu.org
> Date: Mon, 01 Oct 2012 11:13:04 -0400
> 
> > Since about 2 weeks ago, I see these warning messages while
> > bootstrapping on MS-Windows, when Lisp files are being byte-compiled.
> 
> Hmm.. you should have seen them since when I introduced the
> eager-macroexpansion, which is a bit more than 2 weeks.

What can I say? I don't bootstrap too often ;-)

> >   Warning: Eager macro-expansion skipped due to cycle:
> >     Γאª => (load "erc-backend.el") => (macroexpand-all (defun erc-server-connect Γאª)) => (macroexpand (erc-log Γאª)) => (load "erc.el") => (load "erc-backend.el")
> 
> [ Not sure what this Γאª is about, but I'll assume it's some incorrect
>   encoding of … ]

Most probably.  The Windows console is notorious for screwing up
non-ASCII characters, since the encoding used by GUI applications and
by console programs is different.

> > AFAICS, all of these messages are related either to loading tramp.el
> > or erc-backend.el.  But I may have missed others, not sure.
> 
> Yes, IIRC there are two such problematic cycles, one with Tramp and
> another with ERC (there were a couple more, but I fixed them).
> I'm not completely sure how best to fix them, so I preferred to leave
> them in and wait for the ERC and Tramp maintainers to fix them later.
> They're harmless in the sense that the resulting .elc files should be
> correct (and probably even identical).
> 
> I think the warning prints a clear and concise description of the cycle,
> so it should not be too hard for the maintainers of those packages to
> understand the problem and decide how best to fix it.
> 
> > and its subroutines.  I never saw anything similar in "regular" byte
> > compilation after updating from the master repository, FWIW.
> 
> A bootstrap under GNU/Linux shows those same warnings.

Thanks for the info.

bug#12548: 24.2.50; Eager macro-expansion skipped due to cycle

[Drew Adams]

Perhaps this should be merged with bug #12473?

bug#12548: 24.2.50; Eager macro-expansion skipped due to cycle

[Stefan Monnier]

> Perhaps this should be merged with bug #12473?

No, 12473 is an actual bug (that is fixed in the trunk AFAIK).


        Stefan

bug#12548: 24.2.50; Eager macro-expansion skipped due to cycle

[Drew Adams]

> > Perhaps this should be merged with bug #12473?
> 
> No, 12473 is an actual bug (that is fixed in the trunk AFAIK).

Really?  I received no notification that it has been fixed.
In fact, I've received no reply at all after my posting that bug.

bug#12548: 24.2.50; Eager macro-expansion skipped due to cycle

[Glenn Morris]

This is explained in NEWS, so can this be closed?

bug#12548: 24.2.50; Eager macro-expansion skipped due to cycle

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 12548@debbugs.gnu.org
> Date: Tue, 02 Oct 2012 02:47:34 -0400
> 
> 
> This is explained in NEWS, so can this be closed?

I think the relevant maintainers (erc and Tramp) should be made aware
of this, and hopefully fix the problem reported here.

bug#12548: 24.2.50; Eager macro-expansion skipped due to cycle

[Glenn Morris]

Eli Zaretskii wrote:

>> This is explained in NEWS, so can this be closed?
>
> I think the relevant maintainers (erc and Tramp) should be made aware
> of this, and hopefully fix the problem reported here.

It's just that there are many warnings compiling Emacs, this one is
harmless, and we don't normally open reports for them all. (Also, no
offence meant to anyone, but I'm not sure if anyone is maintaining erc,
and I don't think they would find this report anyway.)

bug#12548: 24.2.50; Eager macro-expansion skipped due to cycle

[Glenn Morris]

PS also this for several files:

Compiling emacs-lisp/ert-x.el
Warning: Eager macro-expansion skipped due to cycle:
    => (load "gv.el") => (macroexpand-all (defun gv--defun-declaration
    )) => (macroexpand (pcase  )) => (load "pcase.el") =>
    (macroexpand-all (defmacro pcase-let  )) => (macroexpand (dolist  ))
    => (load "gv.el")


PPS does using the ellipsis character add anything?
As you can see I lost it during copy-paste from a graphical Emacs to a
-nw one; and it was somehow corrupted in the initial report.

bug#12548: 24.2.50; Eager macro-expansion skipped due to cycle

[Stefan Monnier]

> Compiling emacs-lisp/ert-x.el
> Warning: Eager macro-expansion skipped due to cycle:
>     => (load "gv.el") => (macroexpand-all (defun gv--defun-declaration
>     )) => (macroexpand (pcase  )) => (load "pcase.el") =>
>     (macroexpand-all (defmacro pcase-let  )) => (macroexpand (dolist  ))
>     => (load "gv.el")

I think this is the problem due to "loading cl.el causes pcase's use of
dolist to load cl-macs, which loads gv, which loads pcase, ...".
The occurrence of this problem depends on when pcase gets byte-compiled
(since pcase.elc does not require macroexpansion of dolist).

The best fix I can think of is to ban cl.el's dolist, but I have the
strange feeling this suggestion is not going to fly.

> PPS does using the ellipsis character add anything?

As compared to using "..."?  It's more concise.
As compared to not writing it at all, the advantage is that it preserves
the Elisp syntax, making the result more clear.


        Stefan

bug#12548: 24.2.50; Eager macro-expansion skipped due to cycle

[Stefan Monnier]

>> This is explained in NEWS, so can this be closed?
> I think the relevant maintainers (erc and Tramp) should be made aware
> of this, and hopefully fix the problem reported here.

I hope the byte-compiler warning will do that for us.


        Stefan

bug#12548: 24.2.50; Eager macro-expansion skipped due to cycle

[Glenn Morris]

Stefan Monnier wrote:

> The best fix I can think of is to ban cl.el's dolist, but I have the
> strange feeling this suggestion is not going to fly.

You mean, drop cl.el's alias of dolist to cl-dolist? Irrespective, it
would be good to do that to remove the confusion of having two
"dolist"s. I guess it depends whether anyone was actually intentionally
requiring cl to get the cl version of dolist...


For the erc one, looks like just moving erc-log and erc-with-buffer from
erc to erc-backend (or a new erc-macs) would solve it. erc requires
erc-backend, so this could not cause any problems other than aesthetic
ones.

bug#12548: 24.2.50; Eager macro-expansion skipped due to cycle

[Stefan Monnier]

>> The best fix I can think of is to ban cl.el's dolist, but I have the
>> strange feeling this suggestion is not going to fly.
> You mean, drop cl.el's alias of dolist to cl-dolist?

Yes.

> Irrespective, it would be good to do that to remove the confusion of
> having two "dolist"s.

Yes.

> I guess it depends whether anyone was actually intentionally requiring
> cl to get the cl version of dolist...

There are definitely users of CL's dolist (i.e. uses of dolist where the
body uses `return').

> For the erc one, looks like just moving erc-log and erc-with-buffer from
> erc to erc-backend (or a new erc-macs) would solve it. erc requires
> erc-backend, so this could not cause any problems other than aesthetic
> ones.

I suggest you send the patch to the ERC maintainers to see what they
think of it.  It's not like it's an urgent problem to fix.


        Stefan

bug#12548: 24.2.50; Eager macro-expansion skipped due to cycle

[Glenn Morris]

Stefan Monnier wrote:

> I suggest you send the patch to the ERC maintainers to see what they
> think of it.

I don't think there are any.

http://savannah.gnu.org/projects/erc

has no commits in over 3 years.

>  It's not like it's an urgent problem to fix.

No, so I guess we can close this report after all...

bug#12548: 24.2.50; Eager macro-expansion skipped due to cycle

[Stefan Monnier]

>> I suggest you send the patch to the ERC maintainers to see what they
>> think of it.
> I don't think there are any.
> http://savannah.gnu.org/projects/erc
> has no commits in over 3 years.

Hmm... I guess we should ask Michael Olson if he still considers himself
maintainer, and if not, just install whichever patch we think is
cleanest (and update the `erc' package on Savannah to redirect the
curious to the Emacs package).


        Stefan

bug#12548: 24.2.50; Eager macro-expansion skipped due to cycle

[Michael Olson]

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

I've been eyeballing patches that get sent to emacs-devel and Cc:'d to me
and signing off on them, but not doing much more than that.  We had a
maintainer volunteer a couple years ago, but haven't heard from him since.

I think it would be reasonable to modify sv.gnu.org/p/erc to point to the
Emacs package.  The only other users of that package would be users of
Emacs 21 or XEmacs.  Emacs 21 doesn't matter much anymore, and XEmacs
already has ERC in their source tree I believe, with their own patches.

On Wed, Oct 3, 2012 at 10:46 AM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

> >> I suggest you send the patch to the ERC maintainers to see what they
> >> think of it.
> > I don't think there are any.
> > http://savannah.gnu.org/projects/erc
> > has no commits in over 3 years.
>
> Hmm... I guess we should ask Michael Olson if he still considers himself
> maintainer, and if not, just install whichever patch we think is
> cleanest (and update the `erc' package on Savannah to redirect the
> curious to the Emacs package).
>
>
>         Stefan
>



-- 
Michael Olson  |  http://mwolson.org/

[-- Attachment #2: Type: text/html, Size: 1716 bytes --]

bug#12548: 24.2.50; Eager macro-expansion skipped due to cycle

[Glenn Morris]

Michael Olson wrote:

> I think it would be reasonable to modify sv.gnu.org/p/erc to point to the
> Emacs package.

If you log in to your Savannah account, you should be able to add a
notice to the erc front page. An explicit notice to erc-announce would
probably be good too.

Do you want us to set "Maintainer: FSF" in all lisp/erc/*.el files
(except erc-desktop-notifications.el)? None of the listed
authors/maintainers have made any changes in ~ 4 years.

bug#12548: 24.2.50; Eager macro-expansion skipped due to cycle

[Michael Olson]

On Fri, Oct 5, 2012 at 1:21 PM, Glenn Morris <rgm@gnu.org> wrote:
> Michael Olson wrote:
>
>> I think it would be reasonable to modify sv.gnu.org/p/erc to point to the
>> Emacs package.
>
> If you log in to your Savannah account, you should be able to add a
> notice to the erc front page. An explicit notice to erc-announce would
> probably be good too.

Done.

> Do you want us to set "Maintainer: FSF" in all lisp/erc/*.el files
> (except erc-desktop-notifications.el)? None of the listed
> authors/maintainers have made any changes in ~ 4 years.

Sounds good.

-- 
Michael Olson  |  http://mwolson.org/