This commit introduces a quantity Lambda.max_arity that is the maximal
number of parameters that a Lambda function can have.
Uncurrying is throttled so that, for example, assuming the limit is 10,
a 15-argument curried function fun x1 ... x15 -> e
becomes a 10-argument function (x1...x10) that returns a 5-argument
function (x11...x15).
Concerning untupling, a function that takes a N-tuple of arguments,
where N is above the limit, remains a function that takes a single
argument that is a tuple.
Currently, max_arity is set to 126 in native-code, to match the new
representation of closures implemented by #9619. A signed 8-bit field
is used to store the arity. 126 instead of 127 to account for the
extra "environment" argument.
In bytecode the limit is infinity (max_int) because there are no needs
yet for a limit on the number of parameters.
Now that atoms have black headers, all zero-sized blocks (atoms or
ocamlopt-generated static data) have black headers and will not
be traversed or changed by the major GC.
Atoms are zero-sized blocks allocated outside the heap.
It simplifies the GC in no-naked-pointers mode if their headers
have GC color Black, meaning "don't traverse".
In ocamlopt, Black is already used as the color for constant blocks
statically allocated outside the heap.
Here we start reaping the benefits of the new closure representation.
The fields of a closure block that contain the code pointers need not
be scanned (in general) and must not be scanned (in no-naked-pointers mode).
Here, conservatively, we skip them in no-naked-pointers mode only,
but it would be sound to skip them unconditionally.
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
Add a "closure information" field after each code pointer in
a closure. This field generalizes the "arity" field used by
the native-code compiler, in that it has room both for an arity
(always 0 in bytecode) and for the distance from the closure
to the first environment variable in the closure block.
This makes closures "self-described" and easy to scan for pointers:
everything up to the first env var is out-of-heap code pointers or
integers; everything after the first env var is a well-formed value.
At this point a bootstrap is needed.
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.
This patch makes Unix.time and Unix.gettimeofday be unboxed and @noalloc, which makes them about 20% faster (as measured by a stupid benchmark that does them many times in a loop).
This removes the fallback and error-handling paths from gettimeofday. Neither is needed according to Single Unix Specification and POSIX.
Fixes: #7446
* Undefine the CAML_DEBUG_SOCKET variable early
So that if the debugged program creates or executes another program
that happens to be an OCaml bytecode executable, said program does
not try to connect to the debugger at beginning of execution.
Fixes: #8678
* Check availability of setenv() and unsetenv()
And guard the use of unsetenv() in runtime/debugger.c.
In -no-flat-float-array mode, instead of always returning
`best_msig` (the most permissive signature), we first compute the
flat-float-array separability signature -- falling back to `best_msig`
if it fails.
This discipline is conservative: it never rejects -no-flat-float-array
programs. At the same time it guarantees that, for any program that is
also accepted in -flat-float-array mode, the same separability will be
inferred in the two modes. In particular, the same .cmi files and
digests will be produced.
Before we introduced this hack, the production of different .cmi files
would break the build system of the compiler itself, when trying to
build a -no-flat-float-array system from a bootstrap compiler itself
using -flat-float-array. See #9291.
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.