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>");
}
