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

[Maurizio Cimadamore]

Had a chat with Anna from jetbrains - it seems the problem has to do 
with supertypes with $ in their names - which are currently ignored by 
the IDE.

While we could wait for a fix, perhaps changing the name of these 
artifacts (which, at the end of they day are not exposed to users) might 
be better in the long term.

Maurizio

On 11/12/2020 21:34, Maurizio Cimadamore wrote:
> For the records I already contacted JetBrains on a related issue, 
> caused by this fix:
>
> https://youtrack.jetbrains.com/issue/IDEA-247596
>
> In that case the problem even appeared with source completion - 
> basically skipping all symbols inside the classes with $ in their 
> names. Their fix basically filtered the autocompletion output so that 
> these classes were skipped (considered as internal).
>
> It is possible that by fixing that issue (which I no longer see on 
> 2020.3) some other regression kicked in.
>
> Maurizio
>
> On 11/12/2020 18:56, Paul Sandoz wrote:
>> I too have had problems with IntelliJ, not recognizing methods or 
>> autocompleting. I suspect we need to file a bug as the code 
>> arrangement is a little unusual.
>>
>> Paul.
>>
>>> On Dec 11, 2020, at 10:39 AM, Filip Krakowski 
>>> <filip.krakowski at hhu.de> wrote:
>>>
>>> Hi,
>>>
>>> sorry for all the mails. Turns out IntelliJ's autocompletion let me 
>>> think the method was only accessible through "ucx_h$0". Importing it 
>>> using "import static org.openucx.ucx_h.copysign;" works just fine. 
>>> Switching to class mode again yields "Cannot resolve symbol 
>>> 'copysign'". I think I will stick with source mode until IntelliJ is 
>>> able to handle the generated class files.
>>>
>>> Best regards
>>> Filip
>>>
>>> On 11.12.20 19:30, Filip Krakowski wrote:
>>>> Hi,
>>>>
>>>> just tried it out using source mode. Here I also get source files 
>>>> with numbered suffixes (e.g "ucx_h$1.java", "ucx_h$2.java") in 
>>>> which the classes are declared package-private. These classes 
>>>> contain public static methods which I therefore cannot access.
>>>>
>>>>     /class ucx_h$0 {//
>>>>     //
>>>>     //    /* package-private */ ucx_h$0() {}//
>>>>     //    public static  MethodHandle copysign$MH() {//
>>>>     //        return ucx_h$constants$1.copysign$MH();//
>>>>     //    }//
>>>>     //    public static @C("double") double copysign (@C("double")
>>>>     double __x, @C("double") double __y) {//
>>>>     //        try {//
>>>>     //            return
>>>>     (double)ucx_h$constants$1.copysign$MH().invokeExact(__x, __y);//
>>>>     //        } catch (Throwable ex) {//
>>>>     //            throw new AssertionError(ex);//
>>>>     //        }//
>>>>     //    }/
>>>>
>>>>
>>>> Here "ucx_h$0" is package-private which makes the public static 
>>>> method "copysign" inaccessible. Shouldn't these classes be public?
>>>>
>>>> Best regards
>>>> Filip
>>>>
>>>> On 11.12.20 18:59, Filip Krakowski wrote:
>>>>> Hi,
>>>>>
>>>>> I should add that this only happens when a method gets placed 
>>>>> inside a inner class (e.g "ucx_h$1").
>>>>>
>>>>> Best regards
>>>>> Filip
>>>>>
>>>>> On 11.12.20 18:56, Filip Krakowski wrote:
>>>>>> 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