bug#58601: 29.0.50; Infinite loop in byte-compile--first-symbol-with-pos

[Basil L. Contovounesios]

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