[m-rev.] for post-commit review: a start on getting type repn info from .int files

[Zoltan Somogyi]

2021-07-22 11:52 GMT+10:00 "Peter Wang" <novalazy at gmail.com>:
> tests/invalid has a list of SINGLEMODULE programs, which are tested
> without generating dependencies first. That has the side effect of NOT
> creating the .int file before errorchecking the module.

Then how did the .int files get generated ok for Julien and me
during a workspace bootcheck?

Part of the problem may be that invalid/Mmakefile has *two* rules
for making .err files, one each for when using/not using mmc --make,
and they execute different commands. Could this be the root reason
for the disparity of results?

In any case, after we figure out and fix the disparity, the fix to the original
problem seems obvious: have the mmake rules in invalid generat
 the .int files even for singe module programs.

> Commit e627efcf5 introduces this call in
> grab_plain_opt_and_int_for_opt_files:
> 
> +    % This compiler invocation can get type representation information
> +    % for all the types it has access to in the .int and/or .int2 files
> +    % of the modules it imported directly or indirectly, *except* for
> +    % the types it defines itself. For representation information for
> +    % these types, it must read its *own* .int file.
> +    process_module_int1(Globals, rwi1_type_repn, ModuleName,
> +        _SelfParseTreeInt1, !HaveReadModuleMaps, !ModuleAndImports, !IO),
> 
> That tries to read the <mainmodule>.int file, which doesn't exist,
> so it adds an error to !ModuleAndImports, which is the source of the
> new error messages:
> 
> +mercury_compile: cannot find `abstract_solver_type.int' in directories .,
> +  /mnt/testing/run/build/mercury-srcdist-rotd-2021-07-21/stage2/library,
> +  /mnt/testing/run/build/mercury-srcdist-rotd-2021-07-21/stage2/browser,
> +  /mnt/testing/run/build/mercury-srcdist-rotd-2021-07-21/stage2/mdbcomp,
> +  /mnt/testing/run/build/mercury-srcdist-rotd-2021-07-21/stage2/ssdb

I almost certainly would have jumped immediately to this as the cause of the
error messages if I could *see* those error messages, but the testing web page
has only irrelevant snippets of error messages, *not* the full logs of the failed
tests. (I asked for that when testing.mercurylang.org was being set up in
early august 2018.) Yes, there is a link to the full log, but searching that log
in a web page is far harder in a web page than in a file, especially when you are
(as I was) out on an errand, and have only a phone, whose browser simply
does not have "search in this page" functionality. (Or if there is one,
it is well hidden :-()

> 2. In tests/invalid run:
> 
>     WORKSPACE=../../stage2 mmake MC=lmc runtests_dir
>     (any workspace will do)

What difference would MC=lmcN make if the installed compiler
already has the commit from july 1?
 
> Or just compile any single module program with intermodule optimisation,
> e.g.
> 
>     % ~/local/stow/mercury-srcdist-rotd-2021-06-30/bin/mmc --intermod-opt hello
> 
>     % ~/local/stow/mercury-srcdist-rotd-2021-07-19/bin/mmc --intermod-opt hello
>     mercury_compile: cannot find `hello.int' in directories .,
>       /home/wangp/local/stow/mercury-srcdist-rotd-2021-07-19/lib/mercury/ints

Running "mmc mod1.m mod2.m" already does not work without having created
the interface files. This is just one more instance of a multimodule program,
though in this case the other modules are library modules. I don't think there is
much point in adding special case code to get this use case working, when
we already have two perfectly good solutions already, mmake and mmc --make.
We just need to document this fact.

Zoltan.