These methods can be declared in the bridge by naming the first
argument self and making it a reference to the containing class, e.g.,
fn get(self: &R) -> usize;
fn set(self: &mut R, n: usize);
This syntax requires Rust 1.43.
These methods can be declared in the bridge by naming the first
argument self and making it a reference to the containing class, e.g.,
fn get(self: &C) -> usize;
fn set(self: &mut C, n: usize);
This syntax requires Rust 1.43.
Note that the implementation also changes the internal naming of shim
functions so that they also contain the name of the owning class, if
any. This allows defining multiple methods with the same name on
different objects.
This change adds specifically, support for &[u8] with a corresponding
rust::Slice<uint8_t> type. No other types of slice are permitted. The
rationale is that it may be common to pass binary data back and forth
across the FFI boundary, so it's more urgent to get this in place sooner.
Broader support for other slices can wait for the future.
But, both C++ and Rust-side bindings should allow the existing support
to be broadened to other Slice types in future without code changes.
A few specific notes:
* The name "rust::Slice" might be better as "rust::SliceRef" but I'm
following the precedent of "rust::Str".
* It would be good to add constructors from std::span but as that's
a C++20 feature, that may have to wait until C++ feature detection
is resolved.
* Internally, this follows the pattern of &str, where the parser will
initially recognize this as Type::Ref (of Type::Slice) but then
will replace that with Type::SliceRefU8. Type::Slice should not
persist through later stages. As we later come to support other
types of slice, we would probably want to remove Type::SliceRefU8.
If the user's cxx::bridge invocation includes any header that defines
the following function, they get it's behavior as the exception-to-Result
conversion.
namespace rust::behavior {
template <typename Try, typename Fail>
static void trycatch(Try &&func, Fail &&fail) noexcept try {
func();
} catch (/* up to you */) {
fail(/* const char *msg */);
}
}
The default behavior is equivalent to:
} catch (const std::exception &e) {
fail(e.what());
}
Codebases that use Folly, for example, may be interested in behavior
like this instead for better type information on the error messages:
} catch (const std::exception &e) {
fail(folly::exceptionStr(e));
} catch (...) {
fail("<unknown exception>");
}
Not currently usable as a function argument or explicit return value,
but will be required when we introduce Result for the case of fallible
void functions, whose return type will be Result<()>.
https://doc.rust-lang.org/std/boxed/index.html:
So long as T: Sized, a Box<T> is guaranteed to be represented as a
single pointer and is also ABI-compatible with C pointers (i.e. the C
type T*).
Clang-format doesn't always like the same ending comment as the start of
the block. In particular it wants:
inline namespace cxxbridge01 {
...
} // namespace cxxbridge01
This avoids collision with the user's namespaces having the same name.
Less important in the context of the current names right now, but more
important after we move our public C++ API from cxxbridge:: to rust::.
In fact our example code already uses org::rust:: as the namespace,
inside of which a non-absolute rust:: would cause trouble.