[m-rev.] C# bootcheck

[Zoltan Somogyi]

My bookcheck in the C# grade yielded a few more (78) test failures,
which were in line with my expectations after the Java bootcheck.

The attached diff (which I have committed) should fix a few of these
for both Java and C#. I will see if I can reduce the number of unexpected failures
further not just by fixing the compiler problems causing them, but also
by disabling tests that these grades cannot pass (for now, at least),
or by listing them as expected failures in these grades. Are there
any objections?

One problem is that tools/bootcheck -jN does not seem to work
for Java and C#. When I try it, then Out.cs_parallel shows that
I get errors like this:

Making Mercury/int3s/mer_std.int3
Making Mercury/int3s/mer_std.int3
Making Mercury/int3s/mer_std.int3
** Error making `Mercury/int3s/mer_std.int3'.
cp: cannot stat 'Mercury/int3s/mer_std.int3.tmp': No such file or directory
Error creating `Mercury/int3s/mer_std.int3': can't open input file: No such file or directory
Error: problem updating interface files.

Am I right in guessing that this is caused by bugs in mmc --make when invoked
in parallel mode? If yes, this seems like a fundamental bug that would warrant
disabling parallel mode until fixed. If not, does anyone know at least roughly
what part of the system is going wrong? It is pretty annoying to have a new
6-core laptop and not being able to use 5 of them :-(

Something else that concerns me are the differences between the C# source files
in stages 2 and 3. Out.cs.gz shows that pretty much all of these are concerned
with numbers at the extreme edge of representability, like this:

--- stage2/compiler/Mercury/css/ml_backend.mlds_to_java_data.cs 2019-06-18 01:21:06.220434988 +0200
+++ stage3/compiler/Mercury/css/ml_backend.mlds_to_java_data.cs 2019-06-18 01:53:18.045123091 +0200
@@ -11837,7 +11837,7 @@
       if (succeeded)
       {
         int Var_15 = 0;
-        int Var_16 = unchecked((int) 0xffffffff);
+        int Var_16 = -1;
         string Var_20 = null;
         string Var_21 = null;

My guess is that the condition of output_int_const_for_csharp is behaving differently
when compiled in hlc.gc than when compiled in csharp grade. Can anyone who speaks
C# more fluently than me verify this? And maybe fix that difference?

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Out.cs.gz
Type: application/gzip
Size: 87012 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20190618/725f9601/attachment-0001.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.aiih
Type: application/octet-stream
Size: 1183 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20190618/725f9601/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Out.cs_parallel
Type: application/octet-stream
Size: 320010 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20190618/725f9601/attachment-0003.obj>