This job did actually do two different things:

1. Check that the compiler can be built without the world.opt target

2. Run sanitizers

This commit thus splits the extra-checks job into two separate
ones that are defined as Jenkins pipeline jobs named sanitizers and
step-by-step-build.

The macro \libdocitem{Bigarray} was including `refman/extension/bigarray.etex`.
Rewriting the macro to input `library/#1.tex` instead of `#1.tex`
avoids this issue and should be hopefully less brittle in the future.

1. Modified Location.absolute_path to do mapping for
BUILD_PATH_PREFIX_MAP regardless of whether the
path is relative or absolute. Previously it only
did it for relative paths.

2. Because of ocaml#1, deleted Location.absolute_path_always.

3. In bytelink.ml, move make_absolute locally within link_bytecode
and do not do BUILD_PATH_PREFIX_MAP rewriting.
In this case the path is what goes in the shebang, and
I do not see how we would want rewriting in that case,
unless there was a later processor to rewrite the
shebangs.

4. Update man page and manual for the revised
BUILD_PATH_PREFIX_MAP spec (approval pending).

Note this is a work in progress. The changes will be split
into multiple PRs.

In order to produce reproducible builds (independent of the location
of the build), starting from Dune 3.0, Dune has mapped references to
the workspace directory to “/workspace_root”.

This change enables ocamldebug to recover the locations of the source
code. The ocamldebug user must set the BUILD_PATH_PREFIX_MAP
environment variable to effect the mapping.

If we only want to map "/workspace_root" to a single directory, say
mydir, we would do:

export BUILD_PATH_PREFIX_MAP="mydir=/workspace_root"

If we want to map to multiple directories, we must separate
them with ';'.

So to map to mydir1 and mydir2, the setting would be:

export BUILD_PATH_PREFIX_MAP="mydir1;mydir2=/workspace_root"

Then if ocamldebug has a path like

"/workspace_root/stuff",

this is converted to the list

["mydir1/stuff" "mydir2/stuff"]

Add "mapping" debugger variable to control BUILD_PATH_PREFIX_MAP.

In order to allow the BUILD_PATH_PREFIX_MAP environment variable to be
set from within ocamldebug, a new debugger variable, "mapping" has
been added. It works with the usual set and show commands. When set,
the value is put into BUILD_PATH_PREFIX_MAP in ocamldebug's
environment, just as if it had been set before entering ocamldebug.
And showing it give the current value, including the value on
entry, if set.

This also makes it possible to set it from .ocamldebug files.

The manual and man pages have been updated to describe
the change.

1. I added four tests for the ocamldebug support for
BUILD_PATH_PREFIX_MAP. One test shows that if
debug paths are sanitized by the compiler, then
the debugger is unable to find the sources.
The other three tests show three ways to provide
the BUILD_PATH_PREFIX_MAP to ocamldebug:
a. Setting environment variable externally.
b. Setting the "mapping" ocamldebug variable
in an input script.
c. Setting the "mapping" ocamldebug variable
in a ".ocamldebug" file.

2. To write the tests I needed a way to have
script or ".ocamldebug" files that had ocamldebug
variables expanded. I did not see a way to do
that, so I added a new "expand" action to
ocamltest. It is mostly like the "copy" action,
but the source file is read a line at a time
and the lines are expanded. It does not
support source directories, but the
destination can be a directory.

3. I used a dumper to look at the directories
in the debug information and noticed that
there were still some unsanitized directories.
I tracked the source of these in the compiler
and modified so all debug directories are
sanitized.

More ocamltest enhancements, add/fix tests

1. I enhanced ocamltest to have a facility for making
builtin functions. These are like ocamltest variables
but have a function attached to them, and when
the variable is expanded, the arguments are first
expanded and then the function is called and its
result is returned.

2. Added a new "dumpenv_expanded" action which not
only shows the value of each variable, but also what
the they expand to. When variables are originally
assigned, their RHS is not expanded, but only
later when the variable itself is looked up.

3. Two builtin functions were defined:

- bppm_decode does BUILD_PATH_PREFIX_MAP decoding
- bppm_encode does BUILD_PATH_PREFIX_MAP encoding

4. Tests of the new builtin functions were added.

5. The debugger prefix mapping tests were
modified to use bppm_encode. They, in fact,
where the motivation for the ocamltest changes.

Use load/install printer trick to add ocamldebug unit test

When a printer is loaded and installed into the debugger,
it has access to the internals of the debugger.

I factored out the function that does the
BUILD_PATH_PREFIX_MAP processing in ocamldebug and was able to
unit test it with code in the fake printer.

Modify for revised BUILT_PATH_PREFIX_MAP spec

I decided the problem I was addressing for the debugger
was more general and that the BUILT_PATH_PREFIX_MAP
spec should be generalized to handle it.

See richardlford/build-path-prefix-map-spec#1.

1. Modified BUILT_PATH_PREFIX_MAP handling accordingly
2. Used the new facilities in ocamldebug
3. Updated one test for the new spec.
4. Modify encoding and decoding functions in ocamltest.

Avoid adding dir to Load_path if already their, some test changes

Sanitize paths in debug events

Previously we were sanitizing the debug directories
but were assuming the paths in debug events were
relative. But if the user passes an absolute path
to the compiler, it was putting absolute paths
in the debug events.

Alway rewrite in Location.absolute_path

1. Modified Location.absolute_path to do mapping for
BUILD_PATH_PREFIX_MAP regardless of whether the
path is relative or absolute. Previously it only
did it for relative paths.

2. Because of ocaml#1, deleted Location.absolute_path_always.

3. In bytelink.ml, move make_absolute locally within link_bytecode
and do not do BUILD_PATH_PREFIX_MAP rewriting.
In this case the path is what goes in the shebang, and
I do not see how we would want rewriting in that case,
unless there was a later processor to rewrite the
shebangs.

4. Update man page and manual for the revised
BUILD_PATH_PREFIX_MAP spec (approval pending).

Prepare to be able to do Dune tests

1. Added a action helper for testing if a program
is available in PATH.

2. Use the helper to make an action, has_dune,
that detects whether dune is available.

Fixes ocaml#12083

* starting from rescript-nextjs-template starter, remove some irrelevant parts, fix out of date portions, upgrading most of the files to rescript syntax, and configure vercel deploy

add netlify cms proxy support for local development

Automatically generated. Merged on Netlify CMS.

Add GraphQL API boilerplate

The toplevel printer detects cycles by keeping a hashtable of values
that it has already traversed.

However, some OCaml runtime types (at least bigarrays) may be
partially uninitialized, and hashing them at arbitrary program points
may read uninitialized memory. In particular, the OCaml testsuite
fails when running with a memory-sanitizer enabled, as bigarray
printing results in reads to uninitialized memory:

```
==133712==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x4e6d11 in caml_ba_hash /var/home/edwin/git/ocaml/runtime/bigarray.c:486:45
    #1 0x52474a in caml_hash /var/home/edwin/git/ocaml/runtime/hash.c:251:35
    #2 0x599ebf in caml_interprete /var/home/edwin/git/ocaml/runtime/interp.c:1065:14
    #3 0x5a909a in caml_main /var/home/edwin/git/ocaml/runtime/startup_byt.c:575:9
    #4 0x540ccb in main /var/home/edwin/git/ocaml/runtime/main.c:37:3
    #5 0x7f0910abb087 in __libc_start_call_main (/lib64/libc.so.6+0x2a087) (BuildId: 8f53abaad945a669f2bdcd25f471d80e077568ef)
    #6 0x7f0910abb14a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2a14a) (BuildId: 8f53abaad945a669f2bdcd25f471d80e077568ef)
    #7 0x441804 in _start (/var/home/edwin/git/ocaml/runtime/ocamlrun+0x441804) (BuildId: 7a60eef57e1c2baf770bc38d10d6c227e60ead37)

  Uninitialized value was created by a heap allocation
    #0 0x47d306 in malloc (/var/home/edwin/git/ocaml/runtime/ocamlrun+0x47d306) (BuildId: 7a60eef57e1c2baf770bc38d10d6c227e60ead37)
    #1 0x4e7960 in caml_ba_alloc /var/home/edwin/git/ocaml/runtime/bigarray.c:246:12
    #2 0x4e801f in caml_ba_create /var/home/edwin/git/ocaml/runtime/bigarray.c:673:10
    #3 0x59b8fc in caml_interprete /var/home/edwin/git/ocaml/runtime/interp.c:1058:14
    #4 0x5a909a in caml_main /var/home/edwin/git/ocaml/runtime/startup_byt.c:575:9
    #5 0x540ccb in main /var/home/edwin/git/ocaml/runtime/main.c:37:3
    #6 0x7f0910abb087 in __libc_start_call_main (/lib64/libc.so.6+0x2a087) (BuildId: 8f53abaad945a669f2bdcd25f471d80e077568ef)
    #7 0x7f0910abb14a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2a14a) (BuildId: 8f53abaad945a669f2bdcd25f471d80e077568ef)
    #8 0x441804 in _start (/var/home/edwin/git/ocaml/runtime/ocamlrun+0x441804) (BuildId: 7a60eef57e1c2baf770bc38d10d6c227e60ead37)

SUMMARY: MemorySanitizer: use-of-uninitialized-value /var/home/edwin/git/ocaml/runtime/bigarray.c:486:45 in caml_ba_hash
```

The only use of hashing in genprintval is to avoid cycles, that is, it
is only useful for OCaml values that contain other OCaml values
(including possibly themselves). Bigarrays cannot introduce cycles,
and they are always printed as "<abstr>" anyway.

The present commit proposes to be more conservative in which values
are hashed by the cycle detector to avoid this issue: we skip hashing
any value with tag above No_scan_tag -- which may not contain any
OCaml values.

Suggested-by: Gabriel Scherer <[email protected]>

Signed-off-by: Edwin Török <[email protected]>
Co-authored-by: Edwin Török <[email protected]>

Found by -fsanitize=memory -fsanitize-memory-track-origins:
```
> ==102752==WARNING: MemorySanitizer: use-of-uninitialized-value
>     #0 0x7f2ba7fb4ea4 in caml_runtime_events_read_poll /var/home/edwin/git/ocaml/otherlibs/runtime_events/runtime_events_consumer.c:496:18
>     #1 0x7f2ba7fbc016 in caml_ml_runtime_events_read_poll /var/home/edwin/git/ocaml/otherlibs/runtime_events/runtime_events_consumer.c:1207:9
>     #2 0x59ba5c in caml_interprete /var/home/edwin/git/ocaml/runtime/interp.c:1058:14
>     #3 0x5a9220 in caml_main /var/home/edwin/git/ocaml/runtime/startup_byt.c:575:9
>     #4 0x540d6b in main /var/home/edwin/git/ocaml/runtime/main.c:37:3
>     #5 0x7f2ba8120087 in __libc_start_call_main (/lib64/libc.so.6+0x2a087) (BuildId: 8f53abaad945a669f2bdcd25f471d80e077568ef)
>     #6 0x7f2ba812014a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2a14a) (BuildId: 8f53abaad945a669f2bdcd25f471d80e077568ef)
>     #7 0x441804 in _start (/var/home/edwin/git/ocaml/runtime/ocamlrun+0x441804) (BuildId: 617637580ee48eff08a2bce790e1667ad09f3b69)
>
>   Uninitialized value was stored to memory at
>     #0 0x7f2ba7fb4e9d in caml_runtime_events_read_poll /var/home/edwin/git/ocaml/otherlibs/runtime_events/runtime_events_consumer.c:497:69
>     #1 0x7f2ba7fbc016 in caml_ml_runtime_events_read_poll /var/home/edwin/git/ocaml/otherlibs/runtime_events/runtime_events_consumer.c:1207:9
>     #2 0x59ba5c in caml_interprete /var/home/edwin/git/ocaml/runtime/interp.c:1058:14
>     #3 0x5a9220 in caml_main /var/home/edwin/git/ocaml/runtime/startup_byt.c:575:9
>     #4 0x540d6b in main /var/home/edwin/git/ocaml/runtime/main.c:37:3
>     #5 0x7f2ba8120087 in __libc_start_call_main (/lib64/libc.so.6+0x2a087) (BuildId: 8f53abaad945a669f2bdcd25f471d80e077568ef)
>     #6 0x7f2ba812014a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2a14a) (BuildId: 8f53abaad945a669f2bdcd25f471d80e077568ef)
>     #7 0x441804 in _start (/var/home/edwin/git/ocaml/runtime/ocamlrun+0x441804) (BuildId: 617637580ee48eff08a2bce790e1667ad09f3b69)
>
>   Uninitialized value was created by an allocation of 'buf' in the stack frame
>     #0 0x7f2ba7fb3dbc in caml_runtime_events_read_poll /var/home/edwin/git/ocaml/otherlibs/runtime_events/runtime_events_consumer.c:402:7
>
```

This is in fact an EV_LIFECYCLE with EV_RING_STOP, which has 0
additional data, and thus msg_length 2:
```
runtime/runtime_events.c:      EV_RUNTIME, (ev_message_type){.runtime=EV_LIFECYCLE}, EV_RING_STOP, 0,
```

Attempting to read from `buf[2]` would read uninitialized data.

Signed-off-by: Edwin Török <[email protected]>

[ci] Add preliminary CI for OCaml-wasm with artifact