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