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

[Zoltan Somogyi]

On Wed, 16 Sep 2026 11:11:10 +1000, Julien Fischer <jfischer at opturion.com> wrote:
> > 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 just temporarily disabled the diagnostic to let it work again.

> > 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.

Yes, but the others will do that too, as will disabling the diagnostic.

> > 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.

Exactly why I don't like 2 and 3 either.

> > 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.

Agreed, at least in the absence of other ideas.

Zoltan.