[m-rev.] for review: rewrite rest of options_file.m

[Zoltan Somogyi]

On Mon, 8 Jun 2020 15:50:34 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
> > Does anyone know whether the functionality of options_file.m has any
> > test cases for it, apart from Mercury.config and Mercury.options files?
> 
> We don't have any additional tests of that functionality.

That is what I figured, but wanted to be sure.

> > I couldn't find any. I do think there should be some, but I am not sure
> > whether these should go in e.g. tests/hard_coded, or in a new subdirectory
> > of tests dedicated to tests of option file handling.
> 
> It should be a new subdirectory; there's enough complication in
> hard_coded as it is.

Agreed. However, we will need tests for both (a) correct options files,
and (b) incorrect options files. I think these belong in two separate
directories. Does anyone object to naming these "options_file"
and "invalid_options_file" respectively?

> (Incidentally, running the test suite directly, by doing "mmake
> runtests" in the top-level tests directory, no longer works due to your
> changes back in April.  Is that intentional?)

No, it is not intentional. I can't recall when I last used "mmake runtests",
but it was almost certainly more than a decade ago, so I have forgotten
it existed :-(

Do you know *which* changes in April?

> > (In those tests, the code in the module(s) being compiled almost
> > doesn't matter, which is a pretty clear point of difference from the
> > contents of all the other test directories).
> 
> Maybe the way we should do option file testing is to have an additional
> output auxiliary output mode for the compiler that dumps the final
> variable - value mapping from all the options files processed in some
> canonical form?

That is an excellent idea, and I will follow it, though we will need more
than one such option, since a single compiler invocation can build
such a map more than once.

> > Any preferences? And does anyone have options files in their own
> > projects that go beyond the usual Mercury.{config,options} files in
> > their complexity that I could use as (parts of) test cases?
> 
> I can provide you with some from G12; however I don't think they're
> intrinsically more complex than anything you will find in the Mercury
> system (so far as options_file.m is concerned).

By complexity, I mean things like use of file includes (nested as well as
nonnested), use of references to both envvars and vars defined in the
options files themselves, and use of quoted strings with all the supported
kinds of escapes.

> >     change over to using trace goals for debugging prints, since continuing
> >     to use debug_make_msg would require a globals structure.
> 
> Capitalize change.
> ...
> One general commment: I think all of the call to be io.read_char should be replaced
> by calls to io.read_char_unboxed.

Will do both of these.

> The diff looks fine.

Thank you.

Zoltan.