LLVM currently ships Go bindings (using the LLVM C API). However, these bindings do not appear to be maintained. They do not even expose opaque pointer compatible APIs, which means that they are essentially unusable with LLVM 15.
This was previously discussed in Future of Go bindings?, and at the time it seemed like there was some hope to get the in-tree bindings maintained again, but it doesn’t look like this happened. As such, I believe we should remove these bindings, and direct people to use the aforementioned out-of-tree implementation instead.
Yeah, I’d be OK removing them - though might be worth tagging this thread in the old thread or tagging folks from that thread in this one, etc. To give them a chance to see it/respond.
Yeah, sounds reasonable. I have found that maintaining the bindings out of tree is a lot more convenient for a few reasons:
The bindings were mostly unmaintained, so it was hard to get patches merged.
It is much easier to link against system installed versions of LLVM like apt.llvm.org and Homebrew (just add the appropriate CFLAGS and LDFLAGS in #cgo lines).
So as long as there are good C bindings, I’m happy
I think these bindings were originally added for llgo, which appears to be dead now.
Looks good to me. The Go tests often caused failures when a new attribute was introduced and contributors usually don’t know how to deal with them. They were also flaky in the past so was disabled as the resolution to Disable the Go binding tests in the precommit CI pipeline · Issue #53017 · llvm/llvm-project · GitHub .
I agree that out-of-tree bindings may be more useful and the maintainers can decide support more than one versions.
+1, I think it is a good thing to remove unmaintained code. If someone ever reappears to modernize these, we can always consider re-adding them in the future.
+1. FWICS the Gentoo ebuild has -DGO_EXECUTABLE=GO_EXECUTABLE-NOTFOUND to force-disable the bindings since LLVM 3.7.0, and we’ve never once been asked to enable them.
