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

[Sundararajan Athijegannathan]

Looks good - nice!

-Sundar

On 16/02/19, 12:44 AM, Maurizio Cimadamore wrote:
> 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
>>