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

[Peter Wang]

On Tue, 27 Aug 2019 08:29:57 +1000 (AEST), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 
> On Mon, 26 Aug 2019 15:00:55 +1000, Peter Wang <novalazy at gmail.com> wrote:
> > Unfortunately the problem is not limited to unify predicates, as in the
> > attached test case.
> 
> Yes, you are right. That leaves changing the arg passing convention
> the only feasible approach.
> 
> > We may need to disable the direct arg optimization
> > until the calling convention can be changed.
> 
> Agreed. The attached diff makes that possible.
> 
> The option it adds *must* be set consistently in *all* the modules of a program,
> including the standard library, so flipping the switch from the current backward-
> compatible "yes" to "no" is a significant user-visible change, but then again,
> changing the calling convention for predicates with direct-arg arguments
> is a user-visible change as well, so we have to bite at least one of those bullets
> sometime. Any opinions on which, and when?

For me, it's fine to break compatibility across rotds. Few users (zero?)
would have such big programs that rebuilds are of any concern.
(1) switch off direct args,
(2) change the calling convention,
(3) switch on direct args.

> Note that we should remove the "where direct_arg is" syntax on type definitions
> sometime, since the compiler can now do at least as good a job as humans
> at deciding when the optimization is applicable (provided it is switched on, of course).
> Flip-the-switch time would be as good a time as any for this, which makes *now*
> a good time for its deprecation.

Sure.

> On a tangentially related topic: I want to add both test cases to the suite,
> but intend to add them under the name gh72a.m and gh72b.m. We have been
> naming test cases bugN.m for Mantis bug N for a long time. Github bug reports
> started much more recently, so they are going over numbers that Mantis has
> already gone over. Naming test cases from github ghN.m will avoid clashes.
> There is already a gh65.m in tests/valid. Any objections to using this naming
> convention from now on?

No objection.

Peter