This commit is delicate and needs a careful review.
The `matcher_of_pattern` function is a temporary measure to reduce the
invasiveness of the patch, and make it easier to review.
(Note for reviewers: in the previous version the Record case had
a funny handling of Any, but it is in fact equivalent to just adding
omegas as we now do in all cases.)
There are two obvious directions for improvement:
- Get rid of matcher_of_pattern and pass a head directly to the
various make_matching_* functions.
- Try to factorize this code with ctx_matcher which, it is now
obvious, does essentially the same thing.
Another, less immediate area of attack would be to consider
a presentation of Pattern_head.t where the Any case can be statically
ruled out -- maybe the description could have two levels, one
isomorphic to option (Any or not?) and one for non-any heads.
- Add the key argument in the description of 'merge'
- Note that the keys of 'union f m1 m2' are a subset of the
input keys, not all the keys, since
bindings (union (fun _ _ _ -> None) m m) = []
- Fix grammar in the descriptions of 'filter', 'union', 'merge'
- Fix mismatched variable name in the description of 'partition'
- Note that 'find' and 'find_opt' return values, not bindings
The original implementation of loc_external_arguments and
loc_external_results was following an older ABI,
where an FP argument passed in an FP register "burns" an integer register.
In the ELF psABI, integer registers and FP registers are used independently,
as in the OCaml calling convention. Plus, if all FP registers are used
but an integer register remains, the integer register is used to pass
the next FP argument.
Fixes: #9515
Using instruction fmv.x.d.
This is necessary to implement the ELF psABI calling conventions,
whereas some FP arguments may have to be passed in integer registers.
The instrumentation code in the instrumented runtime was replaced
with new APIs to gather runtime statistics and output them in a new format
(Common Trace Format).
This commit also exposes new functions in the Gc module to pause or resume
instrumentation during a program execution (Gc.eventlog_pause and
Gc.eventlog_resume).
Use a variable-length encoding (suggested by @stedolan) for dimensions that supports dimensions up to 2^64-1 each.
Change the marshalling identifier for bigarrays:_bigarray ~> _bigarr02
The identifier change reflects a change in the bigarray marshalling format.
The docs on this are out of date: they say runtime warnings are enabled by
default, but the source code has a commit 6c90da4 pointing to
https://github.com/ocaml/ocaml/pull/210 that disables them by default.
It seems like enabling runtime warnings by default never made its way into a
release and the docs could just be updated to say that runtime warnings are
disabled by default.
Signed-off-by: Edwin Török <edvin.torok@citrix.com>
- Deprecate Thread.kill, Thread.wait_read, Thread.wait_write
for reasons explained in the documentation comments.
- Update documentation comments for Thread functions.
- Deprecate ThreadUnix module, documented as deprecated since 2002
(commit 0a47a75d56).
- In the manual, remove leftover mentions of the VM threads
implementation; focus on the system threads implementation.
- In the manual, remove the documentation of ThreadUnix.
Closes: #9206
It's not just on Windows that the length of the command passed to Sys.command
can exceed system limits:
- On Linux there is a per-argument limit of 2^17 bytes
(the whole command is a single argument to /bin/sh)
- On macOS with default parameters, the limit is between 70000 and 80000
- On BSDs with default parameters, the limit is around 2^18.
In parallel, response files (@file) are supported by all the C compilers
we've encountered: GCC, Clang, Intel's ICC, and even CompCert. They all
seem to follow quoting rules similar to that of the native shell
for the contents of the response file.
This commit forces the use of a response file when the total size of
the arguments to the linker is greater than 2^16.
Arguments passed via a response file are quoted using Filename.quote
as if they were passed on the command line.
Closes: #9482Closes: #8549
Follow-up to c5afa9303.
The GCC option -fexcess=precision is supported for C but not for C++.
Some users use ocamlc -c or ocamlopt -c to compile C++ source files,
causing errors since -fexcess-precision=standard was added to the
common C flags in commit c5afa9303.
This commit moves -fexcess-precision=standard to the internal C flags,
so that ocamlc -c and ocamlopt -c will not apply it to C / C++ source files.