[foreign] RFC 8219042: Cross-header layout resolution does not work

[Maurizio Cimadamore]

Hi,
the following patch is inspired from the work that Jorn posted yesterday 
[1]. But it takes it a step further: instead of having the various code 
generators call 'scanMethod' and such, all 'indexing' activity is done 
before hand, when te resolver is first created.

Webrev:

http://cr.openjdk.java.net/~mcimadamore/panama/8219042/

Now, as pointed out, this approach is very ad-hoc; not only it is 
inefficient (it's doing a full reflective scan of all methods in all 
classes of an extracted artifact!), but it's also fragile, as it relies 
on the Java signature to give away some info as to what a layout name 
might resolve to. Consider the following case:

@NativeHeader
interface MyHeader {

@NativeFunction("()u64:${foo}")
Pointer<?> m();

}

In this case, despite there's an entry point for 'm', the signature info 
associated with such an entry is simply insufficient, as there's no way 
to tell which carrier type is associated with the name 'foo'.

It seems to me that there are only two stable solutions in this space:

1) assuming jextract generate an artifact with a single root, we could 
then index all inner classes under that root, to look for structs (this 
depends on the jextract library-centric work)

2) if we don't want to make assumption on the layout of the extracted 
interfaces (which seems hard, especially when considering hand-written 
interfaces), then the only option is to manually define a resolution 
context:


@NativeHeader
@NameContext(@NameMapping("foo", Foo.class))

interface MyHeader {

@NativeFunction("()u64:${foo}")
Pointer<?> m();

}


(name and shape of the annotations TBD).

This way, when the binder creates a resolver, it sets up all the 
necessary mapping from names to layouts. The binder should also check 
the validity of the mappings (e.g. check that Foo.class is a struct and 
that it really defines a layout with name 'foo').

This way, no guesswork is needed, everything is deterministic and 
efficient. And this scales to the context of manually written mutually 
dependent structs - which is probably not an uncommon case when it comes 
to message protocols (no jextract there).

Thoughts?

Maurizio