Starting from the 20th, I will be recovering from a major medical operation. For an unknown length of time, possibly several months, I will be incapacitated from working on this patch.

Ping @jberdine

Ping @jberdine

Rebase

Rebase

I don't have commit permissions to the LLVM repo, so if you need this patch for your own patch, you can commit it yourself.

Update commit message and refine doc comment

Replace const_element with aggregate_element

Rebase onto parent patch

Check for NULL in alloc_temp

Assume all functions may allocate on the OCaml heap

I'm concerned about the diagnostic handler-related functions. An arbitrary OCaml function can be set as the handler, so any LLVM function that invokes the diagnostic handler anywhere may allocate on the OCaml heap, therefore triggering the GC. (This weakens some assumptions that I thought allowed me to omit some instances of CAMLparam in my stacked diff.) What's more, any such LLVM function may throw an OCaml exception, which will unwind the stack, meaning:

https://discuss.ocaml.org/t/relaxed-rules-for-binding-a-c-library/10693/ seems to imply that the shortcuts that this diff makes are still safe.

The original binding code on the main branch often skipped using CAMLparamX and CAMLreturn because many of the functions did not manipulate OCaml heap objects. When converting the bindings to eliminate naked pointers, I followed all the rules at https://v2.ocaml.org/manual/intfc.html because I assumed that to_val might allocate on the OCaml heap. Now, I have a stacked diff at https://reviews.llvm.org/D136537 that assumes that all pointers that LLVM provides OCaml are at least 2-bit aligned, and therefore don't require an allocation on the OCaml heap. This diff also:

Convert the rest of the files

Fix missing CAMLreturn causing hanging tests

Add missing CAMLreturn

Don't use CAML macros in iterator functions

I'm extremely puzzled by https://github.com/llvm/llvm-project/blob/main/llvm/test/Bindings/OCaml/ext_exc.ml. When I test on OCaml 4.14, all tests pass, but when I test on OCaml 5.0~beta1, this test hangs forever. All tests on the parent patch pass on OCaml 5.0~beta1.

Add missing return

Testing...

I wanted to make a stacked diff, but I'm still new to Phabricator and messed it up...

Rewrite commit message

For what it's worth, in my local repository, I redefined to_val to the following:

Remove outdated comments

The original code defined caml_alloc_tuple_uninit, which either called caml_alloc_small or caml_alloc_shr. Then, the original code would initialize the allocation by passing the pointer to the LLVM C API function.

Replace more returns with CAMLreturns in debuginfo

Eliminate unsafe uses of caml_alloc_small

Wrap data in CAMLlocal1

I apologize for my sloppy handiwork in my previous patch... I just noticed this mistake.

Superseded by https://reviews.llvm.org/rGd226244ae0f5b85d21c9cd23f27f1d7890ea3b4f.

Run clang-format on changes

Consistently use the name [sp] for address space

I now made https://reviews.llvm.org/D135524, which is an alternative to this patch. For context, see https://discourse.llvm.org/t/i-accidentally-created-a-naming-inconsistency-in-the-ocaml-api/65715. I intend for either one or the other to be merged depending on which my reviewers think is more appropriate.

According to https://llvm.org/docs/OpaquePointers.html#version-support, LLVM 16 will not support typed pointers. So, if this patch is not going into an LLVM 15 minor or patch release, could one totally remove the old pointer_type and qualified_pointer_type functions and give their names to pointer_type2 and qualified_pointer_type2? However, that involves rewriting the tests, which use the old functions, and I'm not an expert on what all the tests are supposed to check...

Also, I chose not to use the word "opaque" in the docs because once typed pointers are phased out, *all* pointers will be opaque pointers.

Make doc comment of pointer_type2 refer to getUnqual, not get

Per the discussion on https://discourse.llvm.org/t/i-accidentally-created-a-naming-inconsistency-in-the-ocaml-api/65715, I renamed the pointer_type_in_context function I previously added. Because this function takes an address space as an argument, I decided to rename it to qualified_pointer_type2, rather than pointer_type2, to match the existing qualified_pointer_type function, which also takes an address space as an argument. Then, I added another function, pointer_type2, which uses the opaque pointer API and does not take an address space as an argument, to correspond with the pointer_type function.

Thank you for the approval! I do not believe I have permissions to merge, as I just joined Phabricator to make this patch. According to this: https://www.llvm.org/docs/Phabricator.html#committing-a-change

Just rearranged the test order at the bottom to match the order of test definition...

[llvm-ocaml] Add binding for constructing opaque pointers

I just updated the diff to remove the PointerType::isOpaque binding I added. The only reason I added that was to write a test case checking if a pointer was opaque, which I had *misunderstood* and written incorrectly, as @nikic pointed out. As @aeubanks pointed out, users should assume that all pointers are opaque now (as LLVM is migrating to opaque pointers), so the isOpaque binding perhaps should not be added.

[llvm-ocaml] Add binding for constructing opaque pointers

Also, as I update this patch using the "make a new branch and squash merge" method, my reviewers' inline comments still appear, but are shown on the "new" version of the patch where I fix the issue, which creates a confusing context. I want to know if I'm doing the Phabricator workflow correctly, or if there is something else I should be doing.

[llvm-ocaml] Add binding for constructing opaque pointers

It turns out that @nikic was correct to be fishy by pointing out that a "test" I added should not have passed! I figured out that I added the test function, but I had not added it to the list of tests at the bottom of the file, so it never ran. When I did run it, the test did indeed fail. I've updated the diff to fix this, as well as to add the missing word "space" in a doc comment that was pointed out.

[llvm-ocaml] Add binding for constructing opaque pointers

I've updated the patch by making a new feature branch and squash merging the old one into the new one. Now, both my commits are included in the diff. Was there a better way for me to have done this?

[llvm-ocaml] Add binding for constructing opaque pointers

In D134916#3826248, @nikic wrote:

I think your update overwrite your previous changes, which added pointer_type_in_context? Now you're just adding pointer_type_is_opaque (but the tests still use the other function as well).

Hi, I am a first-time contributor to LLVM. I just requested a review from the last two people to make commits to the OCaml LLVM bindings, because I wasn't sure who the code owner was. For context, see https://discourse.llvm.org/t/guidance-for-doing-my-first-contribution/65590/3. Please let me know if I'm doing anything wrong!

[llvm-ocaml] Add binding for llvm::PointerType::isOpaque