Introduce the type Cmm.exttype to precisely describe arguments to
external C functions, especially unboxed numerical arguments.
Annotate Cmm.Cextcall with the types of the arguments (Cmm.exttype list).
An empty list means "all arguments have default type XInt".
Annotate Mach.Iextcall with the type of the result (Cmm.machtype)
and the types of the arguments (Cmm.exttype list).
Change (slightly) the API for describing calling conventions in Proc:
- loc_external_arguments now takes a Cmm.exttype list,
in order to know more precisely the types of the arguments.
- loc_arguments, loc_parameters, loc_results, loc_external_results
now take a Cmm.machype instead of an array of pseudoregisters.
(Only the types of the pseudoregisters mattered anyway.)
Update the implementations of module Proc accordingly, in every port.
Introduce a new overridable method in Selectgen, insert_move_extcall_arg,
to produce the code that moves an argument of an external C function
to the locations returned by Proc.loc_external_arguments.
Revise the selection of external calls accordingly
(method emit_extcall_args in Selectgen).
When the hash function and the internal representation of hash tables
was changed in 4.00, some compatibility code was left so that "old"
hash tables (created with OCaml < 4.00 and marshaled to files)
could still be operated upon by the functions of the new implementation.
This was 9 years ago, so it is reasonable to expect that none of these
"old" hash tables are still in use.
This commit removes the compatibility code in stdlib/hashtbl.ml.
It still tries to detect "old" hash tables and raise an
Invalid_argument exception instead of crashing.
Implement (in utils/binutils.ml) a simple parser for ELF, Mach-O and PE shared object files. Use it to get rid of libbfd in ocamlobjinfo and to improve the checking of external primitives during linking in ocamlc.
Instead of the erasure scheme that was used up to now, where we
considered that the type was always principal.
Note: the erasure still happens when polymorphic variants appear in the
patterns, and the type of the scrutinee contains a Reither.
Add hint when a module is used instead of a module type or when a
module type is used instead of a module or when a class type is
used instead of a class.
This is another classification macro that requires the page table.
Its only uses in the whole OPAM universe is two of our own tests
(tests/asmcomp/is_static.ml and tests/lib-obj/reachable_words_np.ml)
which are now run only in naked-pointers mode.
Part of the test makes sense only if the runtime system supports
naked pointers and has a page table to distinguish major heap pointers
from out-of-heap pointers.
This part is split off in a new test, lib-obj/reachable_words_np.ml,
conditionalized on "naked_pointers".
This primitive (from runtime/obj.c) is being phased out because
it returns a naked pointer outside the OCaml heap.
Instead, for the test, use a statically-allocated buffer
that is never visible from OCaml.
Expected outputs contain integer values for the "closure info"
field of some closures. These values differ in 32 and 64 bits,
since the arity is stored in top 8 bits. This test would need
different expected outputs for 32- and 64-bit platforms.
To keep things simple, this commit restricts the test
to only run on 64-bit platforms. Since this changes the locations
This PR fixes an old bug in the interaction between [merge_constraint]
and [Typedecl.transl_with_constraint], where
variance (and now separability) are recomputed in an invalid type
environment. See #9624 and the new tests.
Lambda and Clambda distinguish Const_int from Const_pointer only so
that they can pass the information to Cmm. But now that that
Const_pointer is gone from Cmm (#9578), there's no need for the
distinction in Lambda either.
This PR requires a bootstrap, because the .cmo format changes:
Lambda.structured_constant has one fewer constructor. The bootstrap
is in the following commit.
We produce exhaustivity counter-example in the order of the
specialized submatrices. Having submatrices in source order gives the
nice behavior that the clause that would naturally been inserted first
in the source is given first as a counter-example.
Consider for example:
function
| true, true -> true
| false, false -> false
The two counter-examples are (true, false) and (false, true).
Before this patch, (false, true) would be shown first.
After this patch, (true, false) is shown first.
This corresponds to the following natural completion order:
function
| true, true -> true
| true, false -> ?
| false, false -> false
| false, true -> ?
On the other hand, the ordering of the default submatrix, with respect
to the specialized submatrices, is not preserved -- it is always
ordered last.
One could intuitively expect the default submatrix to appear in the
position of the first omega row in the source. We tried this, and
it is not a good idea:
- the change is much more invasive as the interface of
`build_specialized_submatrices` has to change
- the behavior of the result is in fact unpleasant; it is not
intuitive to order counter-examples in this way.
For example, consider:
function
| _, None -> false
| true, Some true -> false
The two exhaustivity counter-examples are (true, Some false)
and (false, Some _). The second comes from the default submatrix:
morally it is (_, Some _), with "some other constructor missing from
the column" instead of the first _. There is no reason to suppose that
the user would want to place this (_, Some _) or (false, Some _)
counter-example first in the completed code; indeed, this intuition
would suggest writing an exhaustive covering of patterns of the
form (_, foo), inserted after the first clause, but then the other
clauses below become unnecessary!
When an omega patterns appears high in the column like this, it is
usually because there is a very specific matching condition to the
rest of its row, that justifies some shortcutting behavior. The
program is typically *not* completed by adding more specific matching
conditions.
This solves exponential-blowup issue with the strict traversal and/or
strict witness computation in cases where an exponential number of
counter-examples is generated. This fixes Stack Overflow and
exponential-time issues on examples using or-patterns heavily,
including one that naturally found its way in real-world user
code (see the following testsuite commit).
We now systematically keep only one counter-example, instead of
letting the type-checker decide whether to discard
counter-examples (in Backtrack_or mode) or to preserve
them (in Refine_or mode).
Note: in the exhaustivity warning, there are sub-messages printed to
indicate that:
- the exhaustivity counter-example is related to an extensible type, or
- that a when-guarded clause does match the counter-example
In both cases the warning is there to explain the counter-example(s)
shown (not a property of all counter-examples); keeping at most one
valid counter-example means that they will be printed less often, but
it is the correct/intended behavior in that case.
Clang's thread sanitizer TSAN reports a (false?) alarm on Unix.system
in multithreaded programs now that Unix.system is implemented
on top of posix_spawn.
This commit replaces Unix.system with Sys.command, which might work
better with TSAN, based on preliminary experiments.
Note that this test is about file I/O, not Unix.system, so the replacement
is acceptable. In parallel, we need to understand what's happening
with TSAN and posix_spawn.
Since #9316 was merged, Cconst_pointer is compiled in exactly the same way as Cconst_int. This commit removes the now-redundant Cconst_pointer and Cconst_natpointer.
This module provides a purely sequential implementation of the
concurrent atomic references provided by the Multicore OCaml
standard library:
https://github.com/ocaml-multicore/ocaml-multicore/blob/parallel_minor_gc/stdlib/atomic.mli
This sequential implementation is provided in the interest of
compatibility: when people will start writing code to run on
Multicore, it would be nice if their use of Atomic was
backward-compatible with older versions of OCaml without having to
import additional compatibility layers. *)
Otherwise, arguments get split at spaces.
This is the same quoting that the Win32 implementation of
Unix.create_process does.
A test was added.
Fixes: 9320
The test takes 14s to run every time we run the checksuite, and it
does not seem to serve an easily identifiable purpose. In theory
similar tests could help detect a performance regression in
exhaustiveness checking, but this test seems to only degrade in
constant factor (#9152 proposed to use ocamlc.opt instead of ocamlc to
run it, but it was declined as "hiding" potential problems, which
suggests constant-factor differences). We do not monitor the testsuite
for 10s timing difference, so it is unlikely that we would notice
a constant-factor difference during automated testing.
caml_alloc returns initialised blocks for tag < No_scan_tag. Otherwise,
initialise the blocks as necessary.
For Abtract_tag, Double_tag and Double_array_tag, the initial contents
are irrelevant.
Uninitialised Custom_tag objects are difficult to use correctly. Hence,
reject custom block allocations through Obj.new_block.
For String_tag, the last byte encodes the string length. Hence, reject
zero-length string objects. Initialise the last byte which encodes the
length to ensure non-negative lengths for uninitialised strings.
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.
* Don't include stdio.h in caml/misc.h
There is no need to include stdio.h in caml/misc.h
This seems to have happened by accident in commit cddec18fde
On OpenBSD, stderr and stdout are macros defined in stdio.h
ppx_expect uses stderr and stdout as identifiers in
collector/expect_test_collector_stubs.c where caml/misc.h is included.
This confuses the C compiler, because the macro will get expanded where an identifier is expected.
* Remove fallback NULL definition in caml/misc.h
ISO C guarantees that NULL is defined in <stddef.h>
* include missing stdio in tests/compatibility/stub.c
We don't want to record the state of the file system at the start
of the compilation in the compiled files.
Consequently, we only add persistent modules to the env summary
if they have an observable action on the initial environment.
This is only the case if they shadow a non-persistent module of the
initially opened library (which can only be Stdlib currently).
Xavier Leroy
Xavier Leroy
John Whitington
David Allsopp
EduardoRFS
Daniel Bünzli
Sébastien Hinderer
Gabriel Scherer
Nicolás Ojeda Bär
Matthew Ryan
Jeremy Yallop
Jacques-Henri Jourdan
Thomas Refis
Florian Angeletti
Enguerrand Decorne
Jacques Garrigue
Leo White
xvw
Bernhard Schommer
Stephen Dolan
Etienne Millon
Greta Yorsh
Sébastien Briais
octachron
KC Sivaramakrishnan
Mark Shinwell
madroach