Excellent!

I have redone my own testing with the latest version of this diff plus changes for the inline comments in this last iteration of review. This test translates each of the bitcode files in llvm-project/llvm/test to a different IR, as well as translating and doing some static analysis on several test programs. This testing did not uncover any issues with this diff.

Adding comments about the reasoning behind e.g. avoiding the write barrier seems like a good idea. I don't know if it would be better to have one comment block near the top of the file, or many comments sprinkled around. There might be a lot of redundancy which would be noisy and easy to get out of sync.

Thanks for persisting with this and tolerating all my comments! This looks like it is getting very close, nice! I'm sorry for the piecemeal reviewing, but making a full pass takes longer than I can usually spend at once and I figure it is better to send comments intermittently rather than save them until the end. So far I have spent most time looking at llvm_ocaml.{c,ml,mli} and not so much on the other files, but I think that llvm_ocaml is just about there.

I agree that the caml_ prefix on caml_alloc_tuple_uninit is probably not a good idea.

In D136400#4137328, @alan wrote:

Remove added CAML macros as jberdine's request

Thanks all, it is great to get more eyes on this!

Argh, I made these comments some time ago and failed to submit them.

I'm concerned about the diagnostic handler-related functions.
...
Is the diagnostic handler feature safe?

Only a partial review so far.

Just a few initial comments so far, I have read and tested this some, but need to do more. Also, I think it would be easier to review if this diff and D136400 were combined into a single diff.

I'm not sure I have all the context, but it sounds like perhaps interpret.c from pr3120 could be a useful test case.

Apologies if this isn't directly related to this patch in particular, but is there a more informative message that could be given than "Migrate to new pass manager"? In particular, for non-C language bindings that currently call LLVMPassManagerBuilderPopulateModulePassManager, any pointers to what functions in the C API should be used instead would be very helpful.

LGTM, though I would prefer if docstrings were added for each of the functions added to llvm_debuginfo.mli.

Looks good, thanks!

Heh, yeah, it seems that the best fix would be to just remove the traces of ounit. I also don't see where they are used, so just removing and seeing if the tests pass in a context with no ounit installed seems like a good plan.

Thanks both!

I am not so familiar with cmake and ocamlfind, what do you think @arbipher? @vaivaswatha?

The rest of the C API uses an "LLVM" prefix. Does it really make sense to use a different one for the DIBuilder functions?

LGTM. No-one should be using enum tags named "Reserved" so I'm not worried about compatibility.

LGTM now, thanks! FTR local testing yields:

❯ ninja bindings/ocaml/all check-llvm-bindings-ocaml
[2598/2599] Running lit suite /Users/jjb/src/llvm-project/llvm/test/Bindings/OCaml

I did a bit of hunting. The name string must be empty or else LLVMBuildFence will assert. It seems to me that

FenceInst *CreateFence(AtomicOrdering Ordering,
                       SyncScope::ID SSID = SyncScope::System,
                       const Twine &Name = "") {
  return Insert(new FenceInst(Context, Ordering, SSID), Name);
}

in IRBuilder.h should be

FenceInst *CreateFence(AtomicOrdering Ordering,
                       SyncScope::ID SSID = SyncScope::System) {
  return Insert(new FenceInst(Context, Ordering, SSID));
}

and LLVMBuildFence should not take Name as an argument.

There is an issue. The fence instruction always returns type void. An SSA name is not permitted for values of type void. The test complains:

> ninja bindings/ocaml/all check-llvm-bindings-ocaml
[17/18] Running lit suite /Users/jjb/src/llvm-project/llvm/test/Bindings/OCaml
FAIL: LLVM :: Bindings/OCaml/core.ml (1 of 16)
******************** TEST 'LLVM :: Bindings/OCaml/core.ml' FAILED ********************
Script:
--
: 'RUN: at line 1';   rm -rf /Users/jjb/src/llvm-project/_build/test/Bindings/OCaml/Output/core.ml.tmp && mkdir -p /Users/jjb/src/llvm-project/_build/test/Bindings/OCaml/Output/core.ml.tmp && cp /Users/jjb/src/llvm-project/llvm/test/Bindings/OCaml/core.ml /Users/jjb/src/llvm-project/_build/test/Bindings/OCaml/Output/core.ml.tmp/core.ml && cp /Users/jjb/src/llvm-project/llvm/test/Bindings/OCaml/Utils/Testsuite.ml /Users/jjb/src/llvm-project/_build/test/Bindings/OCaml/Output/core.ml.tmp/Testsuite.ml
: 'RUN: at line 2';   /Users/jjb/.opam/sledge/bin/ocamlfind ocamlc -cclib -L/Users/jjb/src/llvm-project/_build/test/../lib  -g -w +A -package llvm.analysis -package llvm.bitwriter -I /Users/jjb/src/llvm-project/_build/test/Bindings/OCaml/Output/core.ml.tmp/ -linkpkg /Users/jjb/src/llvm-project/_build/test/Bindings/OCaml/Output/core.ml.tmp/Testsuite.ml /Users/jjb/src/llvm-project/_build/test/Bindings/OCaml/Output/core.ml.tmp/core.ml -o /Users/jjb/src/llvm-project/_build/test/Bindings/OCaml/Output/core.ml.tmp/executable
: 'RUN: at line 3';   /Users/jjb/src/llvm-project/_build/test/Bindings/OCaml/Output/core.ml.tmp/executable /Users/jjb/src/llvm-project/_build/test/Bindings/OCaml/Output/core.ml.tmp/bitcode.bc
: 'RUN: at line 4';   /Users/jjb/.opam/sledge/bin/ocamlfind ocamlopt -cclib -L/Users/jjb/src/llvm-project/_build/test/../lib -cclib -Wl,-rpath,/Users/jjb/src/llvm-project/_build/test/../lib  -g -w +A -package llvm.analysis -package llvm.bitwriter -I /Users/jjb/src/llvm-project/_build/test/Bindings/OCaml/Output/core.ml.tmp/ -linkpkg /Users/jjb/src/llvm-project/_build/test/Bindings/OCaml/Output/core.ml.tmp/Testsuite.ml /Users/jjb/src/llvm-project/_build/test/Bindings/OCaml/Output/core.ml.tmp/core.ml -o /Users/jjb/src/llvm-project/_build/test/Bindings/OCaml/Output/core.ml.tmp/executable
: 'RUN: at line 5';   /Users/jjb/src/llvm-project/_build/test/Bindings/OCaml/Output/core.ml.tmp/executable /Users/jjb/src/llvm-project/_build/test/Bindings/OCaml/Output/core.ml.tmp/bitcode.bc
: 'RUN: at line 6';   /Users/jjb/src/llvm-project/_build/bin/llvm-dis < /Users/jjb/src/llvm-project/_build/test/Bindings/OCaml/Output/core.ml.tmp/bitcode.bc > /Users/jjb/src/llvm-project/_build/test/Bindings/OCaml/Output/core.ml.tmp/dis.ll
: 'RUN: at line 7';   /Users/jjb/src/llvm-project/_build/bin/FileCheck /Users/jjb/src/llvm-project/llvm/test/Bindings/OCaml/core.ml < /Users/jjb/src/llvm-project/_build/test/Bindings/OCaml/Output/core.ml.tmp/dis.ll
: 'RUN: at line 9';   /Users/jjb/src/llvm-project/_build/bin/FileCheck -check-prefix=CHECK-NOWHERE /Users/jjb/src/llvm-project/llvm/test/Bindings/OCaml/core.ml < /Users/jjb/src/llvm-project/_build/test/Bindings/OCaml/Output/core.ml.tmp/dis.ll
--
Exit Code: 134

I will try the tests locally

Thanks! LGTM

Thanks, the docs look good.

Looks good apart from a typo, and a bit more documentation.

Thank you very much @vaivaswatha, that is very helpful!

See https://github.com/jberdine/llvm-project/tree/ocaml for this stack on github.

I have been testing this stack of diffs with a sort of stress test that involves running a system that consumes bitcode and uses the ocaml api to traverse and translate it. The testing has used a range of OCaml GC settings in order to make the GC work much harder and trigger much more often than usual (e.g. Gc.set {(Gc.get ()) with minor_heap_size= 1024; space_overhead= 20}). The reasoning here is that if the bindings are not playing nice with the GC, then there is a higher chance to uncover such issues if the GC runs much more often. This testing has not revealed any issues.

I intend to do some additional testing of this, but put this diff up in the meantime for feedback and perhaps also some wider testing.

LGTM

I looked over the new commit and it is good. Personally I prefer the new style anyhow. :-)

LGTM, thanks!

fix bug spotted in CR, formatting

LGTM

I see, it seems some of the builds are still using a version of OCaml older than 4.06 (from 11-2017). The difference between using caml_alloc_initialized_string and the code with memcpy is about const char * versus char *. If OCaml is configured with immutable strings (the default starting with 4.10), then String_val returns a const char *. I guess that supporting such old versions will necessitate compilation warnings about const.

Ah, I see, the failure is just tidy, go for it then. I don't know if it can be configured, but clang-tidy cannot be obeyed on this code without breaking the build.

Thanks @vaivaswatha for dealing with all my nitpicking! Yes, I've made a final pass over this and it looks good. I'd recheck the build before committing given the CI build failure.

Looks good, thanks! I made a few very minor comments. I agree that the current state of clang-tidy is good. I don't know how to let it know about the OCaml-specific headers, and that e.g. value is a type declared there and it's capitalization is not up for discussion.

appease clang-format