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

[Zoltan Somogyi]

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.

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.

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.

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.

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.

Any other ideas?

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Mantis585.library
Type: application/octet-stream
Size: 7473 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20260916/62752cbb/attachment.obj>