[MLton] MinGW + x86_64

[Matthew Fluet]

>>> Error: ..\lib\mlton\basic\vector.sml 10.29.
>>>  Variable type in structure disagrees with argument signature.
>>>    variable: unfoldi
>>>    structure: _ -> [ 'a t ]
>>>    signature: _ -> [ 'a t  * 'b ]
>>> 
>>> ... I am guessing this is due to a broken upgrade path? However, I don't 
>>> have this problem on the MacOS build. I'm using mlton 20051109 on MacOS 
>>> and MLton 20051202 on MinGW.
>> 
>> Its a broken upgrade path on MinGW.  If you look at mlton/Makefile, there 
>> is code to select stubs when compiling with an out of date compiler. 
>> However, the stubs don't work with MinGW.
>
> I read the comment and saw that it said 'fork' is unavailable. Ok, fine. So, 
> I tried editing the lib/mlton-stubs/mlton.sml to pass spawn* through to the 
> real MLton object  and re-enabled stubs. However, when the bootstrapped 
> compiler runs, it exits immediately with a SysErr (it also is much smaller 
> than it should be).
>
> Shouldn't this approach be preferred to manually working around it on MinGW 
> for each release? After all, disabling the upgrade path for something as 
> minor as a missing fork() call (when we have viable alternatives) is a bit 
> overkill.

It is certainly preferred, but I don't think anyone has been successful at 
it.  I believe that the MinGW binary release is built via 
cross-compilation, rather than boostrap on a MinGW machine.

> For now, on MinGW I just hacked my system header. The only type problem there 
> was that C_INo_t (ino_t) is actually signed. A quick modification to 
> /mingw/include/sys/types.h and MLton compiles further.
>
> At this point, I get past type-checking all the libraries.
> However, now I get a nice type mismatch problem when compiling mllex with the 
> bootstrapped compiler.
>
> It happily succeeds at parseAndElaborate, but fails in xmlSimplify/TypeCheck 
> after detecting that 'word16' != 'word32' giving a Type error: type mismatch. 
> It then helpfully dumps the entire mllex XML IL. =D
>
> Trying a smaller test program:
> val () = print "Hello world\n"
> also gives the same problem.
>
> I would therefore hypothesize that there are two bugs..? One in the basis 
> library related to the new type autodetection, where there is a type mismatch 
> somewhere. The other, in the front-end which failed to detect this type 
> error. I have no idea how to proceed... I'm quite surprised the front-end 
> didn't tell me the location in the basis that causes the problem. Also, the 
> IL dump doesn't say where in the IL the type error occurred, or I might be 
> able to work my way backwards...

That would have been my first hypothesis as well, but it is incorrect. 
The IL dump does say where the type error occurred; it is the first few 
lines of the dump before "let exception Bind ...".  I see from the dump 
that the XML type-checker is complaining about:

    val IRGRP: word32 =
       0x20
    val irgrp: word16 =
       IRGRP

However, if I look at the core-ML code before the defunctorize pass, I 
see:

   val IRGRP: word16 = 0x20,

So, for some reason, the defunctorize pass is changing the type of IRGRP 
(and other constants) from word16 to word32.  That isn't the behavior I 
expect.

> I've commited the c-types.sml which works on MinGW (with hacked C_INo_t). I 
> think that's all you need to reproduce the compile error on linux, right?

Thanks.  I was able to reproduce it, by coping build/lib/self to 
build/lib/x86-mingw and adding an entry to build/lib/target-map. 
(Technically, this reads the x86-linux constants for the x86-mingw 
constants, but it suffices for reproducing the error.)