[m-rev.] for post-commit review: propose a new structure for options.m

[Zoltan Somogyi]

On Mon, 9 Jun 2025 14:26:08 +1000, Julien Fischer <jfischer at opturion.com> wrote:
> I realise it's rather late in the day for a review of this.

But still welcome. My reply is also late ...

> On Wed, 4 Jun 2025 at 12:38, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:

> >      ;       oc_link
> > +            % Options that control how executables, or their equivalents
> > +            % for some target languages, are generated.
> > +            % XXX Subdivide into oc_link_c/oc_link_java/oc_link_csharp.
> > +            % XXX Are the oc_link options that apply to more than one target?
> 
> At the moment, I don't think so.

The options that specify the location of the installed Mercury system are needed
to find the set of installed grades, and in that sense are needed regardless of the
target language. And there are some options that look like they were intended to be
options for C, but which are used for C# as well.

> (A subset of the C runtime flags are supported
> the Java backend.)

I saw no sign of that while working on this diff.

> > @@ -1608,6 +1707,7 @@ optdef(oc_semantics, reorder_conj,                      bool(yes)).
> >  optdef(oc_semantics, reorder_disj,                      bool(yes)).
> >  optdef(oc_semantics, fully_strict,                      bool(yes)).
> >  optdef(oc_semantics, allow_stubs,                       bool(no)).
> > +% XXX These stretch the definition of "semantics" beyond the breaking point.
> >  optdef(oc_semantics, infer_types,                       bool(no)).
> >  optdef(oc_semantics, infer_modes,                       bool(no)).
> >  optdef(oc_semantics, infer_det,                         bool(yes)).
> 
> oc_infer?

Will do.

> > +optdef(oc_config,   max_jump_table_size,                 int(0)).
> > +    % 0 indicates jump tables can be any size.
> > +    % XXX This option works around limitations in 1998 C compilers.
> > +    % Its value should be set automatically by handle_options.m
> > +    % based on the value of the c_compiler_type option.
> 
> As I am sure you are aware, this option predates the addition of
> c_compiler_type. There are two C compilers that require this:
> 
> 1. lcc -- this no longer an issue as Mercury can no longer be
>    built with lcc.
> 
> 2. MSVC -- the configure sets the maximum jump table size to 512
>    "to avoid a fixed limit in the compiler".

At the moment, handle_options.m does not set, or even mention,
this option.

I presume that the reason for handling these implications in configure.ac
is that we need the results in sh scripts, as well as in the compiler.
If you confirm that, I will add a comment to that effect to handle_options.m.

> >  optdef(oc_internal, max_specialized_do_call_closure,     int(5)).
> >      % mercury.do_call_closure_N exists for N <= option_value;
> >      % set to -1 to disable. Should be less than or equal to
> > @@ -2224,14 +2327,17 @@ optdef(oc_buildsys, target_env_type,                    string("posix")).
> >      % Miscellaneous options
> >
> >  optdef(oc_misc,     filenames_from_stdin,               bool(no)).
> > +% XXX Should we add new category, named maybe oc_errors, for options
> > +% that control how and/or when the compiler generates diagnostics?
> > +% Include options that reverse the order of errors, or limit error contexts.

> oc_errors seems a poor name as presumably these options also control the same
> aspects for warnings.  I would be prefer something like oc_diag_out or
> oc_diag_fmt.

Well we print warnings by constructing error_specs ... but your point is valid.
I will use oc_diags or some variant thereof.

> I agree with the rest of the proposals.

Thank you.

Zoltan.