On Jun 23, 2016 1:33 AM, "Andrew McCreight" <amccrei...@mozilla.com> wrote: > > On Wed, Jun 22, 2016 at 1:05 PM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: > > > Now that I'm looking at the hand-written notes that I made in the > > meeting, I notice that the above paragraph fails to say how the > > AddRef, Release and associated cycle collection-related calls are > > routed from C++ to Rust or from Rust to C++. There was some talk about > > vtable hacks, but my recollection is that those got rejected along > > with XPCOM. So as far as I can tell, we are left with the meeting not > > concluding how exactly these calls across the language boundary. > > > > C++ CCed objects don't even all use COM. Maybe the existing non-nsISupports > CC infrastructure could be used for Rust objects. If that doesn't work, > adding explicit support for Rust objects to the CC, like we have for JS, > doesn't seem like it would be too difficult. The CC used to nominally > support arbitrary languages.
Non-nsISupports cycle-collected objects were brought up as what we should do in a way that avoids XPCOM. AFAICT, in this case, the methods need not be virtual, so if we wanted to use a vtable-based solution for cross-language calls, we'd need to make stuff virtual because of the cross-language call mechanism. In the absence of cross-language inlining (LLVM on both sides), which I'm told is not about to happen on Windows, the trickery with "this" to make FFI look C++ish to the C++ caller should inline into a plain function call, which should be preferable to a virtual call. (If we ever get cross-language inlining with clang and rustc, the inlining opportunity would be even better.) _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
