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

[Zoltan Somogyi]

2021-07-22 16:53 GMT+10:00 "Zoltan Somogyi" <zoltan.somogyi at runbox.com>:
> 2021-07-22 14:43 GMT+10:00 "Peter Wang" <novalazy at gmail.com>:
>>> 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.
> 
> Ok, I will look into that.

The attached diff should fix the symptoms for now; it is for post-commit review
by anyone. Fixing the underlying problems will take more work. The log message
details these problems.

After you have read that log message, I have some questions/proposals.

First, should we change  tools/bootcheck so that --test-params is the default?
Julien and I both apparantly forgot its existence; we believed that the
presence of --intermod-opt in Mmake.stage.params would cause the tests
to be done with --intermod-opt, when that is true ONLY with --test-params.
I propose that we should.

Second, what should we do with test cases in tests/invalid which generate
errors when one tries to make dependencies for them? I see three avenues
of approach. (1) Ensure that we never make dependencies for them. (2)
Make dependencies for them, but redirect them to /dev/null, and ignore
the nonzero exit status. (3) Add an option to the compiler that will suppress
both the error messages and the nonzero exit status. And I also see two ways
we could ensure that they get the proper treatment. (A) Create a new variable
(say NODEPEND) in the Mmakefile listing their names, and a  "($NODEPEND):%.err:%m"
rule, or (B) moving them to a new test directory. On this question, I am agnostic,
though (3) would require nontrivial changes in the handling of errors during
dependency generation, which is one of the few parts of the compiler
which prints error messages as it goes along, instead of collecting them up
and printing them all at once.

Third, for the other test cases in tests/invalid*, i.e. the ones for which
making dependencies works without any errors, should (1) we make the
dependencies, and then use the <module>.ints mmake targets, and
maybe related targets, to make the required dependencies, or
(2) just execute mmc --make-short-interface/--make-interface commands
directly in the relevant mmake rules? I would prefer (1).

Fourth, tests/invalid/Mmakefile contains this:

# XXX: with `mmake --use-mmc-make' the ".DEFAULT:" rule seems to take
# precedence over "%.err: %.m" rules.
# XXX: the reason we run the $(MCM) command twice is to avoid doubled up
# error messages, once while making interface files, then the module proper.
# The second time the command is run, only one set of error messages
# should appear.
$(addsuffix .err,$(PROGS)):
        -$(MCM) $@
        if $(MCM) -r $@ > /dev/null 2>&1 ; \
        then false; \
        else true; \
        fi

Does anyone know why the code throws away the output of the
second invocation of $(MCM), when the comment implies that
we actually want to throw away the output of the first invocation?
That code was first introduced in commit 2005, in commit
82722524e484468ebffe4b23ac48370f2e39d046, though it has
been reformatted since, including replacing the original % comment
characters with a make-appropriate #.

BTW, I am reordering the two arms of the if-then-else around
that code to avoid double negation.

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Log.gm
Type: application/octet-stream
Size: 3466 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20210725/4e2264cf/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.gm
Type: application/octet-stream
Size: 4732 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20210725/4e2264cf/attachment-0001.obj>