[m-rev.] for review: --warn-can-fail-functions

[Zoltan Somogyi]

On Wed, 7 Aug 2024 16:45:54 +1000, Julien Fischer <jfischer at opturion.com> wrote:

> On Wed, 7 Aug 2024 at 06:53, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> >
> > For review by anyone. I am seeking feedback mainly about
> > the name and documentation of the new option.
> 
> The name seems fine; you may want to extend the entry in the NEWS file
> to explain
> why this is useful.

I added this paragraph:

  This option is for people who prefer that all functions be total,
  and that functions that compute a value only in some circumstances
  (i.e. partial functions) be expressed as predicates instead.

> > The third attached file lists all the can-fail functions in the standard library.
> > It would be nice to replace these, probably with predicate versions
> > (which some of them probably already have), though they would need
> > a longer process: (a) deprecate by marking as obsolete, (b) wait for a release,
> > and then (c) delete.
> 
> We can certainly go ahead and add missing predicates versions and obsolete the
> function versions now.

I will do that soon, though there is another issue here. I do intend to add obsolete
pragmas for the partial function versions so that we eliminate calls to them from
the rest of the Mercury system now, but should we keep them there? That would be
in effect forcing people to adopt to our preferences. For us, it should be enough
to stop using partial functions ourselves; other people can keeep using them if they like.
However, deleting the obsolete pragmas from the library after we have acted on them
would also *prevent* people who *do* share our preferences from getting the assistance
of the compiler in following our example. What we would need is a pragma that says
*warn about call to this function if a specific option is set*, which we don't have.

> The diff looks fine.

Thank for the review.

> (BTW, did you receive my last response regarding the change to where .prof files
> are placed?)

Yes, but I haven't decided what to do about it. I am thinking about two issues.

One is that the call tree edges of a program will be the same when that program
is compiled in LLDS and HLDS .prof grades *except* if the program uses a
C foreign proc that has a "low_level_backend" or "high_level_backend" attribute,
and has no C foreign_proc with the opposite attribute, since in that case the
Mercury code version of the procedure can add more edges to its call tree.
However, these foreign_proc attributes were only ever intended for implementors,
and their documentation in the language reference manual is commented out,
so for people other than Mercury developers, they effectively do not exist.
This makes .prof files effectively non-grade-specific for them.

The second is that the name of the extension, .prof is misleading. Yes, these files
are used for profiling, but they do NOT themselves contain profiling data. I have
been trying to come up with a suffix name that is accurate, non-misleading *and*
not too long, but have not succeeded.

Zoltan.