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

[Zoltan Somogyi]

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.

>> 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? If yes, then there is no way
to safely use parallel make inside any given test directory.

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?

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

Zoltan.