[m-rev.] for post-commit review: a start on getting type repn info from .int files
novalazy at gmail.com
Thu Jul 22 14:43:37 AEST 2021
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
> 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
The architecture and grade names are hyperlinks. From there you can get
at the individual log files, e.g.
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.
More information about the reviews