[m-dev.] foldl2 and recursive_fold2 in dir.m have the wrong result type

[Julien Fischer]

On Wed, 12 May 2021, Zoltan Somogyi wrote:

> 2021-05-12 20:18 GMT+10:00 "Julien Fischer" <jfischer at opturion.com>:
>> No objections from me. I assume we would eventually deprecate the
>> originals anyway?
>
> Yes.

In that case you can call them something like foldl2_maybe_error etc.
The names won't be permanent since we'll go back to the original ones
after a few releases anyway.

>>> The other thing that we should discuss is why the
>>> list_class_files_for_jar needs to do a complete traversal
>>> of a directory.
>>
>> Because compilation of a single Java source file may result in multiple
>> class files being generated (and definitely will with what the Mercury
>> compiler generates).
>>
>> Nested classes in Java are placed in their own .class files.  For
>> example.
>>
>>     class Foo {
>>         class Bar {}
>>     }
>>
>> will result in the generation of the class files Foo.class and
>> Foo$Bar.java.  For things like anonymous nested classes the naming
>> will involve a "non-empty sequence of digits" (to quote the JLS).
>>
>> There are two reasons why we just search for all the .class files:
>>
>>    1. The Mercury compiler isn't (currently) aware of what class files
>>    the Java compiler will generate for a given generated Java source file**
>>    and ...
>>
>>    2. ... there doesn't seem to be a specific enough naming scheme on
>>    the Java side of things that the Mercury compiler could know.
>>    (The closest I could find is in section 13.1, "The Form of a Binary",
>>    of version 16 of the JLS.)
>
> Are you saying that there is a possibility that two independent test cases
> could be compiled into an *overlapping* set of class files? So if those
> two test cases are executed at the same time,
>
> - test case 1 could create e.g. x.class,
> - test case 1 could then use x.class,
> - test case 2 could overwrite x.class,
> - test case 1 could finish and delete x.class,
> - test case 2 could fail because it cannot find x.class?
>
> Is this theoretically possible?

It could be the case for those test cases that share a module whose
source code is in the tests directory.  It shouldn't occur for
genuinely independent test cases however.

> If yes, then there is no way to safely use parallel make inside any
> given test directory.

One possibility would be to extend mmc --make so that it generates
files for each program target in a separate subdirectory (like
--use-grade-subdirs but at the program level.)

> And another question: since in the presence of parallel make,
> list_class_files_for_jar may return class files that were created
> by other test cases, why are its callers unfazed by having it return
> unrelated class files?

It doesn't.  For each program, the Mercury compiler knows what all of
the top-level class files will be called.  For each top-level class,
Foo, we know that any other classes related to that class (e.g. nested
classes etc) will have a class file name beginning with the prefix Foo$.
The Mercury compiler constructs the set of such prefixes and then includes
all files beginning with those prefixes in the JAR.

> And a last question: is there any reason for why list_class_files_for_jar
> uses dir.recursive_foldl2 instead of variant that ignores errors caused
> by entries in directories that disappear between being read and being opened,
> other than "recursive_foldl2 exists, and it is close enough"?

I'm not sure.  Where is the other version?

Julien.