Call foreign member functions using Panama

[Samuel Audet]

Hi,

This reminds me, it's been a while since I looked at this page, but 
there's a lot more green, and a lot less red, than I remember:
https://clang.llvm.org/docs/MSVCCompatibility.html

My guess is when compatibility gets close enough to 100%, Microsoft will 
start deprecating their cl.exe tool and transition fully to clang-cl. At 
that point, I don't see many C++ compilers choosing to remain 
incompatible with Clang and LLVM. It's going to be just like OpenJDK: 
There are still some Java implementations that are not compatible with 
OpenJDK, but they are rather hard to find and don't have a great impact 
on the community.

Samuel

On 11/28/22 20:11, Maurizio Cimadamore wrote:
> Hi,
> as others have pointed out in this thread, while supporting C++ from 
> jextract/Panama is not impossible, there are several obstacles to get 
> there. The biggest one is that the C++ platform compiler plays a very 
> important role in how things get compiled (e.g. which mangled name an 
> overloaded member function will get, among other things). Often, 
> high-level parsing libraries such as libclang do not offer enough 
> information for jextract to be able to reconstruct the full picture. 
> Even ignoring low-level details such as vtables and inline functions, 
> when we have tried to create a small wrapper around jextract to "lower" 
> C++ code into C we ran into several problems esp. around templates, as 
> the clang API was not exposing information about template instantiation 
> correctly. When researching the problem, we realized that we were not 
> alone, and that e.g. the Rust binding generator tool also suffers from 
> similar issues/limitations:
> 
> https://rust-lang.github.io/rust-bindgen/cpp.html
> 
> Creating a foreign linker implementation based on LLVM bitcode would of 
> course be a much more stable option (and the Linker interface should be 
> generic enough to allow for such implementations). But going down that 
> path would of course introduce additional constraints: users would need 
> their C++ libraries to be compiled into LLVM bitcode. While that might 
> be a possible move for 3rd party libraries (although I'd say still 
> rather uncommon), this present problems when considering system 
> libraries (here, GCC/MSVC still rule on Linux/Windows respectively). So, 
> while the LLVM bitcode seems like an interesting target, I believe 
> something "messier" is going to be needed in the short term (probably a 
> combination of Java fooreign code plus some common C++ library, such as 
> what JavaCPP does, or as described here [1]).
> 
> Maurizio
> 
> [1] - http://cr.openjdk.java.net/~jrose/panama/cppapi.cpp.txt
> 
> On 26/11/2022 06:57, Red IO wrote:
>> I was building a small framework to connect rust and java (jdk 11) for 
>> a project. I build a java class with 1 field a long. Then I added non 
>> static native functions to the class representing the member functions 
>> of the corresponding rust struct. I mangled myself through the jni 
>> nightmare and stored a reference to the rust struct in the long. This 
>> construct simulates first class foreign member function support pretty 
>> well. After building this I thought about Panama. As far as I know 
>> Panama currently only supports C (no concept of member functions). 
>> Wouldn't it be a good idea to support languages like c++, rust and 
>> their member functions? I mean with Panama we can already create 
>> foreign structs. Would it be so far fetched to integrate constructors 
>> and member functions into Panama and jextract?
>>
>> Great regards
>> RedIODev