[m-rev.] for review: finish the "solution" of Mantis bug #585

[Julien Fischer]

On Wed, 16 Sept 2026 at 10:31, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
>
>
> On Wed, 16 Sep 2026 10:07:36 +1000, Julien Fischer <jfischer at opturion.com> wrote:
> > This change has broken standard library compilation in
> > asm_fast.gc.declddebug.stseg.tr
> > (as per the latest build on testing.mercurylang).
>
> Yes, I noticed that about an hour ago myself. The attached file lists
> all the errors in stage2/library; it's not just term_io.m.

No it isn't, that was just the first spot it failed when I tried
reproducing it on my machine.

> For the error in term_io.m, the fix is trivial. It is not trivial for several of
> the other modules, with one example being ordinary_term_to_revstrings
> in string.to_string. Moving all the code fragments that get a typeclass_info
> and use it into predicates of their own would make that code significantly
> harder to read. This exposes the flaw in our understanding of what kinds
> of code have this problem.

The more concerning problem is that ROTD installation with the default grade
selection is broken.

> I have thought of several possible fixes, but none are ideal.
>
> Fix one would be to restrict the test for conflicting typeclass_infos
> not just to modules compiled with typeinfo liveness, but to *procedures*
> to typeinfo liveness. Almost all the procedures complained about
> are private to a library module, and ordinarily, Mercury standard library
> modules are compiled with shallow tracing, meaning that only procedures
> declared in the interface need typeinfo liveness.
>
> This is unattractive, because it does not help any similar problems outside
> the library.

Although it will fix the installation problem.

> Fix two would be to change the severity of any diagnostic from error to
> warning, which, like all warnings, could be shut up by an option.
>
> Fix three would be a new accumulating option that lists the names of
> procedures for which simplify_proc.m would not invoke the test.
> The naming of a procedure in that option would effectively be
> an acknowledgement that the procedure would fail the test.

Fixes (2) and (3) both require maintaining information in Mercury.options files.
If the prevalence of this issue in the standard library is any indication, this
will be burdensome for non-trivial projects.

> Fix four would be to change the test so that what it looks for is not
> "different branches bind different typeclass_infos for the same constraint",
> but "different branches get different typeclass_infos for the same constraint
> FROM AN EXISTENTIAL DECONSTRUCTION". This would be the most
> promising in terms of letting code that has always been compilable
> in debug grades become compilable again, but it has the flaw
> that actually trying to debug the given predicate would still suffer from
> the Mantis 585 bug: attempts to access to a typeclass_info from
> the wrong branch.

I think we will just need to accept that as a limitation of the debugger for
now.

> Any other ideas?

Not for me.  Peter?

Julien.