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

[Julien Fischer]

On Fri, 3 Apr 2026 at 07:06, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:

> Rationalize the code expanding @file cmd line args.

...

> diff --git a/compiler/mercury_compile_main.m b/compiler/mercury_compile_main.m
> index 1085af41a..733b904ee 100644
> --- a/compiler/mercury_compile_main.m
> +++ b/compiler/mercury_compile_main.m

...

> @@ -125,9 +126,20 @@ real_main(!IO) :-
>              write_translations_record_if_any(Globals, !TIO)
>          )
>      ;
> -        ArgResult = apr_failure
> -        % All the error messages that explain the reason for the failure
> -        % have already been printed.
> +        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.

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

The rest looks fine.

Julien.