unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: "Basil L. Contovounesios" <contovob@tcd.ie>
Cc: "Mattias Engdegård" <mattiase@acm.org>,
	58601@debbugs.gnu.org,
	"Stefan Monnier" <monnier@iro.umontreal.ca>
Subject: bug#58601: 29.0.50; Infinite loop in byte-compile--first-symbol-with-pos
Date: Tue, 18 Oct 2022 17:06:59 +0000	[thread overview]
Message-ID: <Y07dM9Yk2LMunhT7@ACM> (raw)
In-Reply-To: <87pmepw0ov.fsf@tcd.ie>

Hello, Basil.

On Tue, Oct 18, 2022 at 19:34:08 +0300, Basil L. Contovounesios wrote:
> Alan Mackenzie [2022-10-18 15:01 +0000] wrote:

> > On Tue, Oct 18, 2022 at 02:24:02 +0300, Basil L. Contovounesios wrote:

> >> I.e. the 'pure' compile-time form has a cycle, and the DFS of
> >> byte-compile--first-symbol-with-pos gets lost.

> > What's a DFS?

> Depth-First Search.

Thanks!

> >> Paraphrasing Stefan, it's acceptable if the compiler mishandles
> >> circular source code, but it should be able to handle circular data.

> > The problem here seems to be feeding macroexp-warn-and-return with data
> > as the FORM argument.

> That's not the problem, because it's just for illustrative purposes.
> Instead of 'arg' being passed unchanged as the FORM argument, it could
> just as well have been `(my-frobnicate ,arg).

That would not loop, since there is a symbol with position there.

> > FORM is intended only to be an executable lisp form.

> `(my-frobnicate ,arg) fits that bill, right?  The end result is the
> same: macroexp-warn-and-return is fed a form containing a cycle, without
> any of the code that gives rise to the form being circular itself.

This would not loop.

> >> I don't know why, but I can reproduce the hang only when the form is inside
> >> ert-deftest+should, and not inside a plain defun.

> > There is a huge concentration of "advanced" features inside those ~20
> > lines of Lisp code.

> Maybe when the compiler detects sufficiently advanced Lisp it should

>   (signal 'indistinguishable-from-magic (list form))

> >  There's eval-and-compile,

> That's just a shortcut: one could equivalently put my-cycle and
> my-identity in a separate file and 'require' it.  The compiler just
> needs to know that my-cycle is pure and my-identity has a
> compiler-macro before reaching their call sites.

> > nconc, a compiler-macro, and ert.  ;-)

> You forgot 'pure'.  We're spoilt for choice!

:-)

> >> Perhaps byte-compile--first-symbol-with-pos needs to employ something
> >> like byte-run--ssp-seen?  Or does ERT somehow come into play?

> > It wouldn't be difficult, just tedious, to add checking for circular
> > lists into byte-compile--first-symbol-with-pos.  But a circular list is
> > an invalid argument for FORM in macorexp-warn-and-return, see above.

> How else should a compiler-macro safely warn about a problematic
> function argument?

by calling the normal byte compiler warning facilities.  If there is a
symbol somewhere in the FORM passed to them, it won't loop, even if it is
a circular list.

You called macroexp-warn-and-return from outside of the byte compiler.
From within the byte compiler, it cannot generate a loop (see above).

> > There are surely lots of places in Emacs where feeding a circular
> > list as an argument to a function will cause a hang.

> Sure, but a subset of those places should reasonably be expected to not
> hang...

Your circular list containing an ordinary symbol (i.e. without position)
is not going to arise in the byte compiler.

> > At the moment, I'm not in favour of doing anything here.  I don't think
> > there's a bug.

> ...for instance, when dealing with compile-time constants in real-world
> Elisp.

Maybe you could construct an example of a circular list without a symbol
from code being compiled.  Maybe you could cause a warning from a correct
call of macroexp-warn-and-return to loop.  But I'd be surprised.

> Thanks,

> -- 
> Basil

-- 
Alan Mackenzie (Nuremberg, Germany).





  reply	other threads:[~2022-10-18 17:06 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-17 23:24 bug#58601: 29.0.50; Infinite loop in byte-compile--first-symbol-with-pos Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-18 14:51 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-18 16:33   ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-18 19:19     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-18 15:01 ` Alan Mackenzie
2022-10-18 16:18   ` dick
2022-10-18 16:34   ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-18 17:06     ` Alan Mackenzie [this message]
2022-10-18 17:39       ` dick
2022-10-18 19:19       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-19  8:52         ` Alan Mackenzie
2022-10-19 12:48           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-21 10:57             ` Mattias Engdegård
2022-10-21 10:47           ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-21 10:47       ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors

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=Y07dM9Yk2LMunhT7@ACM \
    --to=acm@muc.de \
    --cc=58601@debbugs.gnu.org \
    --cc=contovob@tcd.ie \
    --cc=mattiase@acm.org \
    --cc=monnier@iro.umontreal.ca \
    /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).