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

[Julien Fischer]

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.

** When we run the test suite on Windows, even if we use MSVC, we need to
use the Cygwin or MSYS environments, and in those environments the mmc
script is used
(as per every other system).

> The second is: I think printing the name of the script, either mmc or mercury,
> that invoked the executable is way more useful for users than printing the name of
> the executable. From the users' point of view, the latter is an irrelevant detail.
> That is why I don't think io.progname_base can help us here.

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

> We could print "mercury compiler:". That is not the name of the script the user invoked,
> but it will nevertheless identify where the output is coming from sufficiently uniquely,
> regardless of the platform.
>
> > > +        write_error_specs_opt_table(ProgressStream, OptionTable,
> > > +            ArgSpecs, !IO),
> > > +        % In most cases, ArgSpecs should contain errors, so the above
> > > +        % should have set the exit status to 1. However, in cases such as
> > > +        % tests/invalid_options_file/undefined_var.m, it contains
> > > +        % only warnings.
> > > +        %
> > > +        % XXX In such cases, should we get our caller to return apr_success?
> > > +        % And if so, should we do so only with --no-halt-at-warn, or
> > > +        % with --halt-at-warn as well?
> > > +        io.set_exit_status(1, !IO)
> >
> > Unless I have missed something here, compilation should proceed with
> > --no-halt-at-warn (i.e. we should return apr_success) and not proceed with
> > --halt-at-warn. That would be the least suprising behaviour.
>
> If we choose to pay attention to --halt-at-warn, that is exactly what I am proposing.
> However, we can choose not to pay attention to it. ("do so" means "return apr_success"
> above.)
>
> The issue here is that --halt-at-warn is about the compiler setting a failure-indicating
> exit status that prevents either mmake or mmc --make from continuing. It is silent
> about what happens *within* the compiler invocation. From the very beginning, the
> compiler halted early if it found some kinds of problems (such as references to
> undefined types), while it continued after other kinds of problems (such as references
> to undefined predicates and functions). The question that XXX is asking is about
> which category any warnings in ArgSpecs, which mostly warn about undefined
> make variables in Mercury.options files, should belong to.
>
> 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.

Julien.