Make sure to use Receiver trait when extracting object method candidate by compiler-errors · Pull Request #135179 · rust-lang/rust (original) (raw)

Background:

Rust references have certain rules, most notably that the underlying data cannot be changed while an immutable reference exists. That's essentially impossible to promise for any C++ data; C++ may retain references or pointers to data any modify it at any time. This presents a problem for Rust/C++ interop tooling. Various solutions or workarounds are possible:

1. All C++ data is represented as zero-sized types. This is the approach taken by cxx for opaque types. This sidesteps all of the Rust reference rules, since those rules only apply to areas of memory that are referred to. This doesn't really work well enough for autocxx since we want to be able to keep C++ data on the Rust stack, using all the fancy moveit shenanigans, and that means that Rust must know the true size and alignment of the type.

2. All C++ data is represented as UnsafeCell<MaybeUninit>. This also sidesteps the reference rules. This would be a valid option for autocxx.

3. Have a sufficiently simple language boundary that humans can reasonably guarantee there are no outstanding references on the C++ side which could be used to modify the underlying data. This is the approach taken by cxx for cxx::kind::Trivial types. It's just about possible to cause UB using one of these types, but you really have to work at it. In practice such UB is unlikely.

4. Never allow Rust references to C++ types. Instead use a special smart pointer type in Rust, representing a C++ reference. This is the direction in this PR.

More detail on this last approach here: https://medium.com/@adetaylor/are-we-reference-yet-c-references-in-rust-72c1c6c7015a

This facility is already in autocxx, by adopting the safety policy "unsafe_references_wrapped". However, it hasn't really been battle tested and has a bunch of deficiencies.

It's been awaiting formal Rust support for "arbitrary self types" so that methods can be called on such smart pointers. This is now [fairly close to stabilization](rust-lang/rust#44874 (comment)); this PR is part of the experimentation required to investigate whether that rustc feature should go ahead and get stabilized.

This PR essentially converts autocxx to only operate in this mode - there should no longer ever be Rust references to C++ data.

This PR is incomplete:

• There are still 60 failing integration tests. Mostly these relate to subclass support, which isn't yet converted.
• ValueParam and RValueParam need to support taking CppPin<T>, and possibly CppRef<T: CopyNew> etc.
• Because we can't implement Deref for cxx::UniquePtr<T> to emit a CppRef<T>, unfortunately cxx::UniquePtr<T> can't be used in cases where we want to provide a const T&. It's necessary to call .as_cpp_ref() on the UniquePtr. This is sufficiently annoying that it might be necessary to implement a trait ReferenceParam like we have for ValueParam and RValueParam. (Alternatives include upstreaming CppRef<T> into cxx, but per reason 4 listed above, the complexity probably isn't merited for statically-declared cxx interfaces; or separating from cxx entirely.)

This also shows up a Rustc problem which is fixed here.

Ergonomic findings:

• The problem with cxx::UniquePtr as noted above.
• It's nice that Deref coercion allows methods to be called on CppPin as well as CppRef.
• To get the same benefit for parameters being passed in by reference, you need to pass in &my_cpp_pin_wrapped_thing which is weird given that the whole point is we're trying to avoid Rust references. Obviously, calling .as_cpp_ref() works too, so this weirdness can be avoided.
• When creating some C++ data T, in Rust, it's annoying to have to decide a-priori whether it'll be Rust or C++ accessing the data. If the former, you just create a new T; if the latter you need to wrap it in CppPin::new. This is only really a problem when creating a C++ object on which you'll call methods. It feels like it'll be OK in practice. Possibly this can be resolved by making the method receiver some sort of impl MethodReceiver<T> generic; an implementation for T could be provided which auto-wraps it into a CppPin (consuming it at that point). This sounds messy though. A bit more thought required, but even if this isn't possible it doesn't sound like a really serious ergonomics problem, especially if we can use #[diagnostic::on_unimplemented] somehow to guide.

Next steps here:

• Stabilize arbitrary self types. This PR has gone far enough to show that there are no really serious unexpected issues there.
• Implement ValueParam and RValueParam as necessary for CppRef and CppPin types.
• Work on those ergonomic issues to the extent possible.
• Make a bold decision about whether autocxx should shift wholesale away from & to CppRef<T>. If so, this will be a significant breaking change.