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).
Fix tail-call optimisation with a mutable ref
(Clet_mutable was not recognized properly in tail position.)
Add a test for tail-call optimisation with a mutable ref
This commit reverts c1a7ace (originally c545e04), which was a
temporary fix that is no longer needed because it was superseded by
#6608.
The temporary fix caused `{expr with lbl1 = e1; ... }` to not evaluate
`expr` if all labels of its type are overriden. As reported in #7696
this is not desirable. Reverting the temporary fix causes `expr` to
be evaluated always.
As a consequence, a corner case of value "let rec" is no longer accepted.
The corresponding test was updated.
Closes: #7696
This commit exposes all extension constructors when looking up for
a construction with a given type in the environment.
This makes constructor disambiguation work for extension constructors.
Going one step further, when the name of an extension constructors
is misspelled, we cannot rely on the type to find all possible
names. However, since we are in an error path, we have some
path at hand.
Thus, this commit alters the "lookup_from_type" function in the
Constructor module to make it scan the whole environment for
extension constructors with the right type.
This commit should not change anything for labels and standard constructors.
The existing approach requires to set all ocamltest flags at once on
recursive calls. This is very inconvenient if we want to set more than
one flag -- we wish to support choosing both -promote
and -keep-test-dir-on-success.
The Gc.Memprof module provides a low-level API, that will hopefully be
paired with user libraries that provide high-level instrumentation
choices.
A natural question is: how are the higher-level API going to expose
their choice of instrumentation to their users? With the current
Memprof.start API (before this patch), they would have to either
provide their own `start` function wrapping Memprof.start, or provide
a tuple of callbacks for to their users to pass to Memprof.start
themselves.
val start : params -> unit
(* or *)
val callback : params ->
((allocation -> foo option) * (allocation -> bar option) * ... )
With an explicit record, it is easier for libraries to expose an
instrumentation choice (possibility parametrized over
user-provided settings):
val tracker : params -> (foo, bar) Gc.Memprof.tracker
In addition, providing a record instead of optional parameters makes
it much easier to provide "default settings" (helper functions) that
instantiates the types `'minor` and `'ḿajor`, see for example
`simple_tracker` in this patch (which stores the same information for
the minor and major heap, and does not observe promotion), or to later
define checking predicates that can verify that a given choice of
callbacks is sensible (for example: providing a major-dealloc callback
but no promotion callback (dropping all tracked value on promotion) is
probably not a good idea).
Bootstrap: to avoid requiring an awkward bootstrap, this commit keeps
the (now unused) function caml_memprof_start_byt unchanged -- it is
used in the bootstrap binaries, so removing it would break the
build. The intention is to remove it in the following commit.
An error was triggered on the floating point computations because of
rounding errors between the read from the D array, and the C-side fp
computation which used 80-bit precision.
Relative paths are needed in ocamltest (rather than plain executable
file names), because else 'execvp' searches for the executable in the
PATH instead of the current directory.
* Support quoted extensions in comments
* Support quoted extensions in ocamllex
* Support quoted extensions in ocamlyacc
* Fix copying of comments in ocamlyacc
In presence of -annot, the type printer can be requested to print the
inner path of inline records (i.e "t.A"). Before this commit, the
printing of these paths could trigger a lookup to a module with a
invalid name "t".
If this lookup fails this is fine.
However, if there is a cmi file in the environment sharing the name "t",
the lookup can partially succeed (since cmi are not required to start
with a capital letter) until we compare the module name stored in the
cmi with the requested module name.
Obviously, the valid module name "T" of the cmi cannot match the invalid
module name "t" that was requested, and the cmi reader raises a wrong
module file name error.
This commit avoids this whole process by detecting in the type printer
when we are printing an inlined record type constructor.
The separability signature of a type declaration is not inferred in
a principal way, it depends on the order in which GADT equations are
processed. In non-principal cases, we may have two parameters that are
related by an equality, with one of them being given mode Ind and the
other Sep. Either choice of which to make Sep is sound, but (Ind, Ind)
would be unsound.
We change the implementation to ensure that equations are processed in
an order such that the lefmost parameters are the most constained: if
equations imply that ('a = 'b), with the parameter 'a coming before 'b
in the type declaration, and they must be separable, then 'a gets the
mode Sep and 'b gets the mode Ind. This corresponds intuitively to
remembering that 'b is equal to a previous parameter, instead of
remembering than 'a is equal to a not-seen-yet parameter.
Because this changes the separability of standard library types, and
those separabilities are stored in the .cmi files, this commit changes
the .cmi files in the standard libraries in way that appear to require
a bootstrap (it looks like some part of the stdlib is built with
boot/ocamlc and others with ocamlc, and the two should produce/expect
the same .cmi exactly). The bootstrap will come as a separate commit.
This includes two changes: first, in bytegen.ml, we add a pseudo-event after every allocation or closure instruction. Second, in the interpreter, we save the current PC in the interpreter stack in [Setup_for_gc].
They are somewhat difficult to handle for native allocations, and it is not clear how useful they are. Moreover, they are easy to add back since [Gc.Memprof.allocation] is a private record.
This PR was tested with also the -dsel, -dlinear output (also fixed to
not-print locations), but the output is architecture-dependent so this
part of the test was removed.
The user can register several callbacks, which are called for various
events during the block's lifetime. We need to maintain a data
structure for tracked blocks in the runtime. When using threads,
callbacks can be called concurrently in a reentrant way, so the
functions manipulating this data structure need to be reentrant.
This module was originally inspired by js_of_ocaml Misc.MagicNumber module
https://github.com/ocsigen/js_of_ocaml/blob/151b811/compiler/util.cppo.ml#L277-L347
It provides parsing and validation function for magic numbers, that
can tell the difference between "not a valid magic number" and "a
valid magic number, but with another version", and print user-friendly
user messages about it.
It does not contain any knowledge for where to find the magic number
in an OCaml file (this depends on the file format); the parsing
function should be called with an input channel already at the right
position for whichever format is expect.
Before, `man Map` would show:
```
For instance: module IntPairs = struct type t = int * int let compare (x0,y0) (x1,y1) = match Stdlib.compare x0 x1 with 0 -> Stdlib.compare y0 y1 |
c -> c end module PairsMap = Map.Make(IntPairs) let m = PairsMap.(empty |> add (0,1) hello |> add (1,0) world )
```
Now it shows:
```
For instance:
module IntPairs =
struct
type t = int * int
let compare (x0,y0) (x1,y1) =
match Stdlib.compare x0 x1 with
0 -> Stdlib.compare y0 y1
| c -> c
end
module PairsMap = Map.Make(IntPairs)
let m = PairsMap.(empty |> add (0,1) "hello" |> add (1,0) "world")
```
(in both cases the code is in bold)