[foreign-jextract] Using many headers splits generated code in package-private classes

[Filip Krakowski]

Hi,

In my case autocompletion doesn't work either and IntelliJ only shows 
the message "Cannot not resolve symbol 'eventfd'" when I try to import 
it using "import static org.openucx.ucx_h.eventfd;". However, compiling 
and executing a small class calling the function works.

Best regards
Filip

On 11.12.20 18:47, Maurizio Cimadamore wrote:
> The class generation mode has always had issues for me in IntelliJ. 
> Last time I checked, Intellij did not handle the ldc opcode with 
> dynamic constants (condy) internally, which gave issues when e.g. 
> trying to decompile a class.
>
> That said, auto completion at least used to work.
>
> Maurizio
>
> On 11/12/2020 17:41, Filip Krakowski wrote:
>> Hi,
>>
>> looks like I wrote too soon and IntelliJ simply is not able to handle 
>> the generated class files correctly. Is anyone using IntelliJ 
>> (2020.3) and can confirm that it is not able to resolve generated 
>> methods which are created in inner classes? This worked for me in the 
>> past.
>>
>> Best regards
>> Filip
>>
>> On 11.12.20 18:30, Filip Krakowski wrote:
>>> Hi,
>>>
>>> I am trying to generate bindings for the ucx library 
>>> (https://github.com/openucx/ucx). The input I pass to jextract is 
>>> the following header file (filename = "ucx.h", package = 
>>> "org.openucx", source mode = false).
>>>
>>>     /// OpenUCX Transports//
>>>     //#include <uct/api/uct.h>//
>>>     //
>>>     //// OpenUCX Protocols//
>>>     //#include <ucp/api/ucp.h>//
>>>     //
>>>     //// I/O Multiplexing//
>>>     //#include <sys/epoll.h>//
>>>     //#include <sys/eventfd.h>//
>>>     //
>>>     //// File descriptor utilities//
>>>     //#include <fcntl.h>//
>>>     //#include <unistd.h>/
>>>
>>> It looks like a large amount of the generated code ends up in 
>>> numbered package-private classes. As an example, I can't access the 
>>> MethodHandle for "eventfd" because it is in a package-private class 
>>> named "org.openucx.ucx_h$1". If I remove the includes for 
>>> "<uct/api/uct.h>" and "<ucp/api/ucp.h>" the generated method is 
>>> created in class "org.openucx.ucx_h" where I can access it./
>>> //
>>> /Is there a way to access code generated in the other (numbered) 
>>> package-private classes I'm missing?
>>>
>>> Best regards
>>> Filip