[m-rev.] for post-commit review: expanding @file cmd line args

Zoltan Somogyi zoltan.somogyi at runbox.com
Mon Apr 6 09:39:14 AEST 2026



On Fri, 3 Apr 2026 17:29:51 +1100, Julien Fischer <jfischer at opturion.com> wrote:
> On Fri, 3 Apr 2026 at 17:04, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> >
> >
> > On Fri, 3 Apr 2026 15:15:39 +1100, Julien Fischer <jfischer at opturion.com> wrote:
> > > > +        ArgResult = apr_failure(OptionTable, OoMArgSpecs),
> > > > +        ArgSpecs = one_or_more_to_list(OoMArgSpecs),
> > > > +        io.write_string(ProgressStream, "mmc:\n", !IO),
> > >
> > > Hardcoding the name to "mmc" is not ideal; for the MSVC port it will be
> > > "mercury", not "mmc". Why not just use the result of io.progname_base/4
> > > as we do elsewhere?  E.g.
> > >
> > >      io.progname_base("mercury_compile", ProgName, !IO),
> > >      io.format("ProgressStream, "%s:\n", [s(ProgName)], !IO)
> > >
> > > That will return the most appropriate exectuable name: "mmc" on most systems,
> > > "mercury" on Windows and "mercury_compile" if the executable is run directly.
> >
> > There are two issues here.
> >
> > The first is: as this diff shows, there are ten test cases that test what we print here.
> > These will each need one expected output file for each possible string we can print here.
> > For two possible strings, and even three, this is manageable (though not ideal).
> > If more are possible, it may not be. (We cannot use an option that says "always print this
> > here", because one of reasons we can get apr_failure here is that option processing
> > has failed.)
> 
> This is not an issue and only one set of expected outputs is required.
> The Mercury test
> suite cannot run in the environment** (cmd.exe) where the name
> "mercury" is used.
> I am fairly certain that test suite always invokes the compiler via
> mmc rather than
> than directly via the mercury_compile, so that shouldn't show up either.

Ok, thanks for that info.

> io.progname_base does return the name of the script that invokes the executable.
> (The only case where the executable's name is used is where the argument
> vector is not accessible.)

When I tried it out, io.progname_base("mmc", ProgName, !IO) returned "mercury_compile",
which is not what we want to print.

> > As I see them, the choices about what we can do in the presence of such warnings,
> > but NO ERRORS, are
> >
> > - always print the warnings and stop (the current choice),
> > - print the warnings (either now or later), and stop only with --halt-at-warn, and
> > - print the warnings, and continue to the rest of the compilation regardless
> >   of the value halt_at_warn.
> 
> Ok. My preference would be for the second option.

I will switch to that, but not now, because I have changes in progress that would
conflict with it.

Thanks for the review.

Zoltan.





More information about the reviews mailing list