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

[Peter Wang]

On Thu, 22 Jul 2021 14:00:15 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 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?

I don't know. That is a mystery best investigated on your respective
machines.

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

To be clear, you mean that this would no longer be supported:

    mmc --intermod-opt prog.m

unless you first run:

    mmc --make-int prog.m

I'm not objecting to it, just clarifying.

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

The architecture and grade names are hyperlinks. From there you can get
at the individual log files, e.g.

http://testing.mercurylang.org/builds/rotd-2021-07-21/x86_64/
http://testing.mercurylang.org/builds/rotd-2021-07-21/x86_64/hlc.gc/

I will add the underlines to the hyperlinks.

> 
> > 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?

No difference, but the installed compiler might not have that commit.

Peter