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

[Maurizio Cimadamore]

This is meant to be a RFR, despite the (wrong) subject :-)

Maurizio

On 15/02/2019 19:13, Maurizio Cimadamore wrote:
> Hi,
> the following patch clears up some of the issues around layout 
> resolution, by making the resolution support more regular. Instead of 
> second-guessing the user intent, this patch puts forward a 
> well-defined resolution scheme which is independent on the order in 
> which struct types are allocated, allows for better performances (by 
> avoiding tons of reflective scans) and allow for explicit extension of 
> the lookup context.
> Webrev:
>
> http://cr.openjdk.java.net/~mcimadamore/panama/8219042_v3/
>
> The rule of the game are:
>
> * each Panama annotation @Native{Struct, Header, Callback} defines a 
> 'resolutionContext' attribute which points to an array of j.l.Class
>
> * Every Panama construct C is associated with a default resolution 
> root set, which is a singleton set, composed of the outermost class in 
> which C is defined
>
> * if additional resolution roots are provided in the annotation, these 
> are added to the default resolution set
>
> * each class in the resolution root set is traversed, from outermost 
> to innnermost, looking for named entities (such as structs) which are 
> then added to the resolution context
>
>
> This allows us to clean up the existing code, removing calls to 
> 'scanMethods' from the classes generating bound implementation of the 
> Panama interfaces. This also makes the binder more robust and 
> separates the resolution logic from what jextract might want to do in 
> the future (which is an important point: not all structs interfaces 
> will be generated by jextract, although that will be the common case).
>
>
> I've added a test for jextract (although clang/FFI is already 
> exercising this logic), and also a more complete test where I check 
> various scenarios of layout resolution:
>
> * multiple structs nested in same enclosing interafce
> * multiple structs in separate toplevel classes; this has both a 
> negative test (no resolutionContext in the annotation) and a positive 
> test (the right resolutionContext is set)
>
> Thanks to Jorn, Sundar for the helpful discussions!
>
> Maurizio
>