Anonymous structs have strange issues with scala and intellij in ea+44
Jorn Vernee
jbvernee at xs4all.nl
Wed Mar 6 23:09:58 UTC 2019
Hi Mark,
Can you provide the command that is producing that stack trace?
Please note that the `-m` options was removed, and should be replaced by
the `--package-map` option.
Thanks,
Jorn
Mark Hammons schreef op 2019-03-06 23:05:
> Hi Maurizio,
>
> Do you know when an updated ea build will be released with the fix for
> this? I tried to port my application to dotty (a very early,
> experimental version of scala 3), but it seems that dotty is even more
> allergic to the inner classes that jextract is producing than scala 2
> is. For example, it insists that
> usr.include.wayland.wayland_util.wl_list is actually
> usr.include.wayland.wayland_util$wl_list and vice-versa. I've tried
> using one of Shipilev's nightly builds, but it appears jextract is
> broken in that:
>
> [error] jdk.internal.joptsimple.MultipleArgumentsForOptionException:
> Found multiple arguments for option missing-symbols, but you asked for
> only one
> [error] at
> jdk.internal.opt/jdk.internal.joptsimple.OptionSet.valueOf(OptionSet.java:209)
> [error] at
> jdk.internal.opt/jdk.internal.joptsimple.OptionSet.valueOf(OptionSet.java:183)
> [error] at
> jdk.jextract/com.sun.tools.jextract.Main.createOptions(Main.java:180)
> [error] at
> jdk.jextract/com.sun.tools.jextract.Main.runInternal(Main.java:268)
> [error] at
> jdk.jextract/com.sun.tools.jextract.Main.run(Main.java:207)
> [error] at
> jdk.jextract/com.sun.tools.jextract.Main$JextractToolProvider.run(Main.java:363)
> [error] at
> $a0b469e0da23c15d2805$.$anonfun$runTool$1(build.sbt:85)
>
> Thanks,
>
> Mark
>
> On 2/20/19 4:05 PM, Maurizio Cimadamore wrote:
>> Well, not solved, but at least isolated :-)
>>
>> Probably the fix will come in steps - as this issue goes pretty deep -
>> however, to just fix the problem with anon structs we should be able
>> to come up with something quick.
>>
>> Maurizio
>>
>> On 20/02/2019 12:52, Mark Hammons wrote:
>>> I’m glad to hear the problem has been solved. I’ll continue the
>>> project with the workaround I found last night (using java written
>>> helpers to handle these classes with anonymous inner structs since
>>> regular inner structs are fine with scala and IntelliJ as you
>>> mentioned above) and let you know if I hit any other bugs.
>>>
>>> Thanks for the quick work,
>>> Mark
>>>
>>> Mark Edgar Hammons II - Ingénieur d'études at BioEmergences
>>> 0603695656
>>>
>>>> On 20 Feb 2019, at 12:03, Maurizio Cimadamore
>>>> <maurizio.cimadamore at oracle.com> wrote:
>>>>
>>>> Btw, anon structs are not relevant - this code:
>>>>
>>>> struct outer {
>>>> struct inner {
>>>> int x;
>>>> } y;
>>>> };
>>>>
>>>> already has a missing InnerClasses attribute entry in outer.class.
>>>>
>>>> Only, in this case the IDE manages to recover the situation, and
>>>> that has to do with the absence of "$" characters. So, all nested
>>>> structs (structs inside other structs) seem to be affected by this -
>>>> but most of the times the IDE is happy (but the bug should be fixed
>>>> nevertheless).
>>>>
>>>> Maurizio
>>>>
>>>>
>>>>> On 20/02/2019 10:52, Maurizio Cimadamore wrote:
>>>>> I found the issue. Consider this example:
>>>>>
>>>>> $ cat test.h
>>>>>
>>>>> struct server {
>>>>> struct {
>>>>> int x;
>>>>> int y;
>>>>> } events;
>>>>> };
>>>>>
>>>>>
>>>>> in the classfile for test$server.class, jextract is omitting an
>>>>> inner class attribute which lists the anon class. That is, a
>>>>> regularly compiled class (with javac) will feature an inner class
>>>>> attribute like this:
>>>>>
>>>>> InnerClasses:
>>>>> public static #6= #5 of #15; // anon$test_h$19=class
>>>>> test$anon$test_h$19 of class test
>>>>> public static #10= #1 of #15; // server=class
>>>>> test$server of class test
>>>>>
>>>>> Whereas the jextracted class will be like this:
>>>>>
>>>>> InnerClasses:
>>>>> public static #20= #2 of #19; // server=class
>>>>> test$server of class test
>>>>>
>>>>>
>>>>> In other words, jextract is failing to mention, in the InnerClasses
>>>>> attributes, all _uses_ of nested classes - which creates problem to
>>>>> all tools. The classfile generated by jextract does not behave
>>>>> according to the JVM specification, which mandates that whenever
>>>>> there's a constant pool entry modelling an inner class, a
>>>>> corresponding entry to the InnerClasses attribute should be added.
>>>>>
>>>>> Thanks for the report.
>>>>>
>>>>> Maurizio
>>>>>
>>>>>> On 20/02/2019 10:19, Maurizio Cimadamore wrote:
>>>>>> Hi Mark,
>>>>>> if my hunch is correct, I believe attempting to reproduce with
>>>>>> Java code might be impossible.
>>>>>>
>>>>>> The problem has to do with the naming scheme AND something in the
>>>>>> bytecode that jextract generates which seems to confuse IDE and
>>>>>> other tools.
>>>>>>
>>>>>> Redundant signature attributes (such as the one pointed out in my
>>>>>> other email) might be a part of the puzzle.
>>>>>>
>>>>>> Rather than attempting to reproduce with Java - it would be more
>>>>>> helpful, I think, to try to come up with a simple header which
>>>>>> exhibits the same issues when programming against it. I plan to do
>>>>>> that next and see if I'm successful. Hopefully I just need an anon
>>>>>> struct.
>>>>>>
>>>>>> Maurizio
>>>>>>
>>>>>>> On 20/02/2019 01:59, Mark Hammons wrote:
>>>>>>> Thanks Maurizio,
>>>>>>>
>>>>>>> I have been trying to reproduce this on my own and I cannot get
>>>>>>> the same behavior. An inner class of a struct with a name like
>>>>>>> anon$backend_h$555 works fine. In the case of every anonymous
>>>>>>> class in this code, scala can't handle it, nor can intellij. I've
>>>>>>> attached the javap of the other anonymous struct bindings I've
>>>>>>> found as well as their host classes. I hope this helps determine
>>>>>>> the issue.
>>>>>>>
>>>>>>> One thing I've noticed in the class files I've given you is they
>>>>>>> all end with something like this:
>>>>>>>
>>>>>>> Signature: #3 //
>>>>>>> Ljava/lang/Object;Ljava/foreign/memory/Struct<Lwlroots/backend_headers/session$anon$session_h$751;>;
>>>>>>> RuntimeVisibleAnnotations:
>>>>>>> 0: #8(#9=s#10,#11=I#12,#13=I#14)
>>>>>>> java.foreign.annotations.NativeLocation(
>>>>>>> file="/usr/include/wlr/backend/session.h"
>>>>>>> line=43
>>>>>>> column=2
>>>>>>> )
>>>>>>> 1: #15(#16=s#17)
>>>>>>> java.foreign.annotations.NativeStruct(
>>>>>>> value="[${wl_signal}(destroy)](anon$session_h$751)"
>>>>>>> )
>>>>>>>
>>>>>>> I dunno if that's the issue or not, I'm not familiar enough with
>>>>>>> bytecode to know that. However, I haven't been able to create an
>>>>>>> innerclass with the anon$backend_h$114 naming scheme that has
>>>>>>> that kind of ending information. I'll try some more tomorrow and
>>>>>>> see if I can't produce a java example that produces the same
>>>>>>> issues.
>>>>>>>
>>>>>>> Mark
>>>>>>>
>>>>>>>> On 2/20/19 2:14 AM, Maurizio Cimadamore wrote:
>>>>>>>> The signature attributes look in order - actually there are some
>>>>>>>> attributes which are not even needed, as in this case:
>>>>>>>>
>>>>>>>> public abstract wlroots.backend$anon$backend_h$444 events$get();
>>>>>>>> descriptor: ()Lwlroots/backend$anon$backend_h$444;
>>>>>>>> flags: (0x0401) ACC_PUBLIC, ACC_ABSTRACT
>>>>>>>> Signature: #36 //
>>>>>>>> ()Lwlroots/backend$anon$backend_h$444;
>>>>>>>>
>>>>>>>>
>>>>>>>> It seems like the code generator always emits a signature...
>>>>>>>>
>>>>>>>> What I suspect is that the tools are confused by the '$' sign,
>>>>>>>> and they are tricked into thinking that "444" is an inner class
>>>>>>>> of "backend_h".
>>>>>>>>
>>>>>>>> I will do some more experiments of this though.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Maurizio
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 20/02/2019 00:28, Mark Hammons wrote:
>>>>>>>>> Sure,
>>>>>>>>>
>>>>>>>>> I'd like to note one thing quickly. Before I was extracting the
>>>>>>>>> jar with an archive extracter and calling javap on the raw
>>>>>>>>> classfiles. Just now I tried "javap -p -v -cp wlroots.jar
>>>>>>>>> wlroots.backend.anon$backend_h$444" and it couldn't find the
>>>>>>>>> class, but "javap -p -v -cp wlroots.jar
>>>>>>>>> wlroots.backend.anon.backend_h.444" had it able to find the
>>>>>>>>> class in question. Ditto for "javap -p -v -cp wlroots.jar
>>>>>>>>> wlroots.backend_headers.session.anon.session_h.751". I'm
>>>>>>>>> attaching my wlroots.jar along with the javap of
>>>>>>>>> wlr_backend.class.
>>>>>>>>>
>>>>>>>>> This seems to be a recurring issue with the anonymous structs
>>>>>>>>> generated by jextract.
>>>>>>>>>
>>>>>>>>> Mark
>>>>>>>>>
>>>>>>>>>> On 2/20/19 1:04 AM, Maurizio Cimadamore wrote:
>>>>>>>>>> Thanks,
>>>>>>>>>> can you please also post the dump of the 'wlr_backend' struct?
>>>>>>>>>>
>>>>>>>>>> Maurizio
>>>>>>>>>>
>>>>>>>>>>> On 19/02/2019 23:56, Mark Hammons wrote:
>>>>>>>>>>> Here's the javap dump. Tell me if there's anything else I can
>>>>>>>>>>> get you.
>>>>>>>>>>>
>>>>>>>>>>> Mark
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On 2/20/19 12:44 AM, Maurizio Cimadamore wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 19/02/2019 23:29, Jorn Vernee wrote:
>>>>>>>>>>>>> I tried to reproduce the problem without using jextract as
>>>>>>>>>>>>> well, but was not able to, so the bug seems to be up to a
>>>>>>>>>>>>> particularity of the classes generated by jextract. I'm not
>>>>>>>>>>>>> sure if the bug should be attributed to jextract or
>>>>>>>>>>>>> IntelliJ though.
>>>>>>>>>>>> I wonder if this could be due to some missing (or, most
>>>>>>>>>>>> likely, just bad) Signature attributes in the resulting
>>>>>>>>>>>> classfile?
>>>>>>>>>>>>
>>>>>>>>>>>> Would you be able to post a 'javap -v -p' dump of the
>>>>>>>>>>>> classfile, so that we can take a look at it and look for
>>>>>>>>>>>> anomalies?
>>>>>>>>>>>>
>>>>>>>>>>>> Maurizio
>>>>>>>>>>>>
More information about the panama-dev
mailing list