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. Andrew > (A remark of mine that was not discussed in the meeting and that I'm > just adding onto the notes now as hopefully relevant to the last > paragraph: If we don't want to hack vtables to make direct virtual > calls between C++ and Rust, one way to use C linkage and FFI but still > have the C++-side calls syntactically look like C++ method invocations > that fit into existing C++-side smart pointers (etc.) is to interpret > pointers returned from Rust as pointers to instances of a C++ class > whose methods do nothing but call FFI functions with "this" as the > first argument as seen in > > https://github.com/hsivonen/encoding-rs/blob/master/include/encoding_rs_cpp.h > .) > > -- > Henri Sivonen > hsivo...@hsivonen.fi > https://hsivonen.fi/ > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
