| commit | 852af08a4461ae48a0b602da37685c167cebf84d | [log] [tgz] |
|---|---|---|
| author | Devin Jeanpierre <jeanpierreda@google.com> | Thu Apr 13 14:32:46 2023 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Thu Apr 13 14:33:19 2023 -0700 |
| tree | 11b53c1dc90131ebc7068a104141f591d13ccb6c | |
| parent | 27e33151d795dfceb3c91dcc1267b0291044d25c [diff] |
Implement "soft" failures for crubit features, but don't use them yet.
Before this CL, failures to generate bindings for an item are almost always treated as a hard error,
because bindings generated in other translation units which (transitively) depend on this one can't
know that it failed. Function items were hardcoded as an exception to this.
After this CL, in addition to function items, any disabled item also is allowed to fail. A function
exists, `has_bindings`, which returns whether or not an item is guaranteed to be present.
(It returns `Maybe` for functions and for disabled items.)
Followup CL(s?) will check this flag when creating things which depend on these soft-disabled items. For example, when creating a type alias, we should check if `has_bindings(type)`, and only generate bindings for the _alias_ if the aliased type itself is guaranteed to receive bindings.
---
My intent originally had been to actually use `generate_item` for this, but as you'd probably have guessed faster than me, we can't really do this after all, because this forms a cyclic dependency. Suppose we want to write bindings for `struct S {S* x;};` -- we need to know, while generating bindings for the `x` field, if `S` will get bindings, which we are doing in the very process of creating bindings for `S`.
The "good" solution might be to have cycle handling, so that if we detect a cycle, we allege that bindings generation will succeed, since the answer is either `true` or irrelevant. But we're on a 2y old version of salsa (it hasn't received any updates), and my understanding was that the next version of salsa will revamp cycle handling. Also, it's pretty gnarly and I don't actually know how to do it in Salsa.
Easier is to move the logic out. I admit this is not as pretty in some ways, but it certainly works and doesn't require fancy cycle detection.
(It's also faster, since we won't need to run bindings generation for all our transitive dependencies -- we can just call `has_bindings`. And really, speed is nice.)
PiperOrigin-RevId: 524104811
Crubit is an experimental bidirectional bindings generator for C++ and Rust.
Please don‘t use, this is an experiment and we don’t yet know where will it take us. There will be breaking changes without warning. Unfortunately, we can't take contributions at this point.
Crubit allows for C++ code and Rust code to call each other without manually wrapping the APIs in an FFI-friendly interop layer. For example, a C++ function like this:
bool IsAbsPath(std::string_view path);
... becomes callable from Rust as if it were defined as:
pub fn IsAbsPath(path: std::string_view) -> bool {...}
Crubit automatically generates ABI-compatible bindings for structs (which can be passed both by value and by reference), functions, and methods, for a large variety of types. (Trivial types, nontrivial types, templated types, etc.)
$ apt install clang lld bazel $ git clone git@github.com:google/crubit.git $ cd crubit $ bazel build --linkopt=-fuse-ld=/usr/bin/ld.lld //rs_bindings_from_cc:rs_bindings_from_cc_impl
$ git clone https://github.com/llvm/llvm-project $ cd llvm-project $ CC=clang CXX=clang++ cmake -S llvm -B build -DLLVM_ENABLE_PROJECTS='clang' -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=install $ cmake --build build -j $ # wait... $ cmake --install build $ cd ../crubit $ LLVM_INSTALL_PATH=../llvm-project/install bazel build //rs_bindings_from_cc:rs_bindings_from_cc_impl