# `objc2` meeting 2024-06-20

Datetime: 2024-06-20T20:00:00Z UTC

Attended: @madsmtm, @simlay and @silvanshade

## Introductions

Who are you?
Why are you here? (Motivation?)

Generally: Improve the user-story for bindings in Rust.

## My general plan for `header-translator`

`header-translator` mostly innovates on `bindgen` with the following things:

- File-to-file
- Nullability attributes
- Configuration file
- Focus on pre-generating rather than generating in `build.rs`

All of these are things that I'd like to upstream into `bindgen` at some point.

### LibTooling / LLVM

@silvanshade can probably say something more about how this works.

@madsmtm is still confused as to the relationship between LibTooling and Libclang and LLVM's headers in general.

In any case, one idea would be to focus on distributing the `header-translator` binary instead of LLVM binaries?

Other thoughts:
- Can we improve Libclang instead?

### Diffing

I'm about to begin on my bachelor's degree, and have plans to develop an algorithm for diffing and merging N similar files, which I will use to generate Apple bindings for all the different targets that we support, and then merging them afterwards.

## Rust Project Goals

The Rust project has [a project goal][c-proj-goal] related to better C interop, I/@madsmtm is considering hijacking that project goal, and using it to improve `bindgen` in general. I haven't talked to @emilio yet, I really should.

[c-proj-goal]: https://rust-lang.github.io/rust-project-goals/2024h2/Seamless-C-Support.html

---
### simlay's general notes:
- How do we generate reasonable documentation for generated bindings? I/@simlay authored https://github.com/madsmtm/objc2/pull/435 a year ago but didn't get around to actually using/evaluating the documentation generated.
### silvanshade's general notes:

- how do we convince people that `libclang` and `bindgen` are not enough?
- the above seemed like a problem when we asked about distributing llvmup components with rustup
- re: how to distribute libraries and tooling
- re: issues related to how to build and link against llvm and clang (external tools)
- re: issues with using ClangImporter (needs swift llvm fork; implications of this wrt to wider adoption)
- discussion of issues regarding pre vs. on-demand generation (objective-C vs C++ vs ...)
- discussion of use of procedural macros vs other approaches
- discussion of approaches used in bindgen vs cxx vs auto-cxx vs cxx-auto
- re: discuss usage of C++ template metaprogramming (type-traits, concepts, SFINAE, etc)
- can we leverage similar facilities from objective-C runtime? (what is available and can we use more?)
- discuss possibility of evolving cxx-auto into a general tool
- use more TMP + runtime introspection
- use less cxx
- bind enough of AST and ClangImporter modules to bootstrap
- re-implement codegen
- beyond C, C++, Objective-C: what about Swift, Mojo?
- discuss crABI?

### silvanshade's libtooling notes:

- libtooling: https://clang.llvm.org/docs/LibTooling.html
- libclang: https://clang.llvm.org/docs/LibClang.html
- some comparison between them: https://clang.llvm.org/docs/Tooling.html

Main point of distinction is (which they note) that libclang does not provide you full control over the Clang AST.

In general LibTooling is a subset of the larger (unstable) LLVM/Clang C++ APIs. It's the fragment oriented most toward developing tools for things like static analysis, and includes additional features like command line parsing, etc., which go beyond the compiler engine APIs. This is what is used for tools like `clang-format`, etc.

Regarding the status of libclang, there are two issues:

1. It has drastically simplified interface to the internal Clang APIs and purposely does not expose complex lower-level functionality (which we really need)
2. It has become somewhat outdated even for it's original purpose, as I understand it

I don't have a good reference for point 2 off the top of my head but I'm pretty sure I've read some notes about this somewhere in the LLVM project and of course it's sort of clear if you really try to start using libclang for advanced purposes.

As for whether it's possible to improve it re: madsmtm's earlier thought, I suspect it's not feasible for a few reasons:

1. We'd have to figure out how to map missing functionality from the C++ APIs into the C
2. We'd have to implement all of that (in C, and then in Rust interfacing with the C)
3. We'd have to go through a probably difficult process of getting all of that upstreamed

My impression of the state of things is that there probably isn't a lot of interest (on the LLVM project) side in improving libclang, because it's so far behind the C++ APIs.

(Having said that, I believe I did see an attempt *somewhere* to develop either a modernized version of libclang or maybe an attempt to add missing functionality. I can't remember where I saw it now though. I thought it might have been this: https://github.com/JuliaInterop/Clang.jl But it sounds like they are just using the stable interface so maybe not.)

Most focus these days seems to be on MLIR related things, and in fact there's currently the problem that Clang itself doesn't really use MLIR and there's some interest in pushing to change a lot of internal stuff over to that. Mojo kind of shows what's possible by fully embracing that approach. (For that matter, Rust doesn't use MLIR either but probably would benefit from it; I believe they face a similar issue with not having good access to the MLIR APIs because they are C++ based.)

**Question from Jan:** Is (lib)clang even the best approach? If we simply need an AST we might be better off with something like [tree-sitter](https://tree-sitter.github.io/tree-sitter/). There is already an ObjectiveC grammar available and the entire application is written in C so interop should be way less of a pain.
- silvanshade: There probably is a tree-sitter grammar but that wouldn't really help us in this particular case because it's not so much about parsing as it is getting access to the fully resolved AST, which requires semantic analysis. (Technically, a more accurate parser could help us some, but in the end, we really don't want to have to re-implement semantic analysis ourselves because it's too difficult.)