[m-rev.] for post-commit review: don't print some ambiguities by default

[Zoltan Somogyi]

2022-07-07 16:28 GMT+10:00 "Julien Fischer" <jfischer at opturion.com>:
> That said, based on the sort of renaming you have been doing recently
> (and that I assume you are using the ambiguity command for), isn't that
> commmand generally useful, not just to Mercury developers?

It can be useful to people other than Mercury developers, but its output
can be hard to understand unless you are a developer. The reason is that
some of the procedure names it reports refer to procedures not written
by the programmer, but created by the compiler. My change to exclude
procedures created by type specialization (by default anyway) reduces
the number of such procedures we now report, but not to zero;
procedures created by unused argument elimination, tupling/untupling,
higher order specialization, loop invariant removal, last-call-modulo-construction
etc still get reported. With the current name mangling scheme, there is
no way to eliminate them all except by either adding a second C version
of the demangling code (in the trace directory) , or by generalizing the
existing C version in util/mdemangle.c. Neither course of action is
appealing. The generalization route would definitely be preferred,
but I think that should only be done either after, or at the same time as,
a radical simplification and systematization of the whole name mangling
scheme, which is complex because it was never designed; it just grew.

There is also the point that the ambiguity command is useful,
but it is useful for a purpose other than debugging, which means that
for anyone who does not know that its implementation is based on
the proc_layout structures that we normally use either for debugging
or deep profiling, its placement in mdb may seem surprising.

Overall, to make it truly useful to non-developers without surprises,
it should be implemented as a separate command, after a redesign
of name mangling.

Zoltan.