This introduces a tiny change of behavior since command line options which affect the
printing of dependencies (-modules, -all, -ml-synonym, -mlfi-synonym) are taken into
account even for files mentioned before on the command-line. This is probably not going to break
anything.
Note: this commit also reverse the ordering of the output, but we will normalize it in the next
commit anyway.
This bizarre patch results in a full test-suite pass for Visual Studio
.NET 2002 & 2003. Without it, the following code segfaults (resulting in
6 failing tests):
```ocaml
#load "unix.cma";;
let (ifd, _) = Unix.pipe ();;
Unix.in_channel_of_descr ifd;;
```
Older Microsoft C compilers can't generate code for casting unsigned
__int64 to double and the __pragma directive is not available for
suppressing warnings.
Visual Studio 6 and earlier have somewhat insane handling of comparisons
with nan values. Provide alternate (slower) versions of float comparison
functions using isnan rather than standardized comparison behaviour.
Support was added for variadic macros in the RTM version of Visual Studio
2005 (CL Version 14), but there are variants of the version 14 compiler
included in SDKs released before Visual Studio 2005 itself which do not
support them. Fix the non-DEBUG version of win32unix to compile correctly
and not display a warning for DEBUG_PRINT calls in
`otherlibs/win32unix/select.c`.
There is still at least one Microsoft-supported version of the CRT which
does not include the secure versions of various functions, and
consequently does not include `_set_invalid_parameter_handler`.
Tests for the definition and inclusion of
caml_install_invalid_parameter_handler refined to detect
`__STDC_SECURE_LIB__` defined in `crtdefs.h`. This is a badly documented,
but standardised, define. Although `__STDC_SECURE_LIB__` is compatible
with MinGW, I have retained the test for `_MSC_VER` and so kept this as an
MSVC-only patch.
Commit 39760599e5 introduced some bogus logic.
Emitting structured constants can register more closures to be emitted. But either
the name of these closures is "unique enough", in which case we don't need the already_translated
argument in transl_all_functions_and_emit_all_constants (and transl_all_functions does not need
to return the set of already emitted functions). Or this is not the case, and the previous code
was wrong since it forgot to remember the set returned by transl_all_functions.
I've fixed the code assuming the latter in order to be on the safe side, but we would probably have
noticed if the former assumption did not hold. I've added a note to the commit mentioned above
so that @chambart can have a look at it.
"Probable" because this was found by code inspection after enabling warning 27. I assume
this could lead to an actual bug in the type-checker, but I have not tried to trigger it.
Fix confirmed by @garrigue.
Alain Frisch
Mark Shinwell
François Bobot
Damien Doligez
David Allsopp
Frederic Bour
Damien Doligez
Jacques-Henri Jourdan