all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Basil L. Contovounesios" via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Alan Mackenzie <acm@muc.de>
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 19:34:08 +0300	[thread overview]
Message-ID: <87pmepw0ov.fsf@tcd.ie> (raw)
In-Reply-To: <Y06/3V4bAByADcz0@ACM> (Alan Mackenzie's message of "Tue, 18 Oct 2022 15:01:49 +0000")

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.

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

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

>> 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?

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

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

Thanks,

-- 
Basil





  parent reply	other threads:[~2022-10-18 16:34 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 [this message]
2022-10-18 17:06     ` Alan Mackenzie
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

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

  git send-email \
    --in-reply-to=87pmepw0ov.fsf@tcd.ie \
    --to=bug-gnu-emacs@gnu.org \
    --cc=58601@debbugs.gnu.org \
    --cc=acm@muc.de \
    --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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.