Anonymous structs have strange issues with scala and intellij in ea+44

[Mark Hammons]

Hi again all,

I started making progress on my project, and I've hit a strange bump in 
the road. I have a type wlr_backend defined as such:

struct wlr_backend {
         const struct wlr_backend_impl *impl;

         struct {
                 /** Raised when destroyed, passed the wlr_backend 
reference */
                 struct wl_signal destroy;
                 /** Raised when new inputs are added, passed the 
wlr_input_device */
                 struct wl_signal new_input;
                 /** Raised when new outputs are added, passed the 
wlr_output */
                 struct wl_signal new_output;
         } events;
};

basically, an anonymous struct. In the latest version, a type is created 
for this struct with the name anon$backend_h$444. However, the 
wlr_backend I get back from the foreign interface does not actually 
return this type. When I was using scala I kept getting weird errors of 
the sort "Class wlroots.backend$anon$backend_h$444 not found - 
continuing with a stub." so I switched to accessing this stuff with pure 
java using the following file:

public class McWayfaceServer {
     public Pointer<wayland_server_core.wl_event_loop> eventLoop;
     public Pointer<backend.wlr_backend> backend;

     public McWayfaceServer(Pointer<wayland_server_core.wl_display> 
display) {
         eventLoop = 
usr.include.wayland.wayland_server_core_h.wl_display_get_event_loop(display);
         backend = wlroots.backend_h.wlr_backend_autocreate(display, 
Callback.ofNull());
     }


     public wlroots.backend.anon$backend_h$444 getBackendEvents() {

     //intellij says this line has a type error

       return backend.get().events$get();
     }
}

IntelliJ marks the line below as erroneous. It says that the actual type 
is wlroots.backend.anon.backend_h.444. However, the code as written 
compiles. I don't know if this is a bug or a change in how java 13 works 
that scala and intellij can't deal with. All I know is that these issues 
didn't exist in the previous release. I can work around them by writing 
java handlers for these types that help scala realize types in question 
so it's not a blocker, but it is an odd behavior change I noticed.

Thanks,

Mark