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.
This is required in order for function pointers like `fn(&CxxString)` to
work, which requires the cxx bridge to emit `fn(&::cxx::CxxString)`
rather than a straight copy of the input tokens.
These were pulled out originally because error message construction was
so verbose that it detracted from being able to follow the logic of the
checks, but now that checks are broken up into finer granularity the
messages can be inlined.
