[m-dev.] [Mercury-Language/mercury] Segfault in only Mercury after solutions in a particular code path (#72)

[Peter Wang]

On Tue, 17 Nov 2020 11:36:13 +1100 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 2020-11-17 11:23 GMT+11:00 "Peter Wang" <novalazy at gmail.com>:
> > On Mon, 16 Nov 2020 17:40:42 +1100 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> >> The idea is that this pass would transform the gh72b.m test case,
> >> which crashes, to the attached code, which works.
> >> 
> >> The only fly in the ointment I can see is that not all references to
> >> a cloned procedure are calls to that procedure. This approach
> >> would not handle the case where the program constructs a closure
> >> using a cloned procedure. In most cases, the closure is then passed
> >> to code that knows its declared signature, and whose implementation
> >> works only with that signature, so this transformation, which changes
> >> the signature, wouldn't work. But at least, the scan of the procedure
> >> bodies can easily be made to find such situations, so we can at least
> >> generate a "sorry, not implemented" error message from the compiler,
> >> instead of a runtime crash.
> > 
> > Can you give an example where this would occur? Is it possible to
> > construct a closure where one of the captured arguments is not ground?
> 
> No, it is not possible to construct such a closure. That is not the problem.
> The problem is that it is possible to construct a closure in which one of
> the *non*-captured arguments needs to be twinned. You cannot simultaneously
> (a) twin the argument for correctness, and (b) have the same signature
> in the target language as other closures with the same *Mercury* signature.

Ah okay.

I'm wondering though: which non-captured argument(s) needs twinning is
based on the higher order inst. The construction of a closure and calls
to that closure must(?) have the same higher order inst information,
so it should be possible to twin the arguments both when constructing
the closure and calling the closure in the same way.
Where am I going wrong?

This is in no way important. Reporting "sorry, not implemented" would be
fine for this rare case.

> > What about a term that contains a direct arg functor with a free
> > argument, e.g.
> > 
> >     R0 = unreviewed(_),	% direct arg functor
> >     Foo = foo(R0, 123),
> >     ...
> >     fill(R0, R),
> > 
> > Could it be possible to write something in the ... such that the
> > construction of Foo cannot be delayed after the call to fill,
> > so that the reference to R0 would be replaced by R?
> > I wasn't able to get the attached example to compile but
> > perhaps it is possible somehow.
> 
> Sorry, but I don't understand what your point is. Can you please explain
> in more detail? What purpose does Foo serve in your example? What
> would replace R0 with R? If it is my transformation, it would operate
> only on code that has already been reordered by the mode checker,
> so it wouldn't have to deal with data flowing towards the left.

(As you say later, I was looking for an example where your proposed
transformation may have to operate on code that cannot be reordered.)

Peter