[foreign] RFR 8218052: Don't throw an exception when encountering a type with a flexible array member

[Henry Jen]

I looked at this before, but not sure if I like it this way and waiting for others to chime in.

First of all, most of the changes is simply pass context around to output the warning. We used to have a static method to get the context, I still think we should have some way to get the running jextract instance and retrieve context from it. I’ll leave it for Sundar to comment on that.

Now to the real discussion about incomplete array support, instead of undefined layout, I prefer to have limited support, we can either strip that field or generate a 0-length array for now. For jextract, C only allow such field at end of struct, and sizeof() operator simply ignore that trailing array field. This should give us a good match as first step.

Move on to more general support, where incomplete array can be in-between layouts. Before that, we probably need to validate some assumption,

Any incomplete array must have length specified in the same struct before the incomplete array. I believe this will pretty much cover most cases if not all. 

With that, I think following should work well enough,

- Not allow to allocate unknown size structure. Meaning if a struct has incomplete array, we won’t be able to allow allocate of it without explicitly provide the size. This can either be done via allocate-then-cast or some helper API does that. 

- An annotation on the incomplete field ’length=<other field reference>’ will tell us how to recover the length of the incomplete array. If that is not specified, the size is unknown and any offset calculation after that field is an error.

Thoughts?

Cheers,
Henry


> On Feb 15, 2019, at 10:40 AM, Jorn Vernee <jbvernee at xs4all.nl> wrote:
> 
> Bump :)
> 
> Updated webrev: http://cr.openjdk.java.net/~jvernee/panama/webrevs/8218052/webrev.01/
> 
> FWIW, I changed the exception into a proper warning message, so most of the changes come from having to pass the Context down to the RecordLayoutComputer.
> 
> Cheers,
> Jorn
> 
> Jorn Vernee schreef op 2019-01-31 13:08:
>> Hi,
>> From the bug description:
>> Currently jextract throws an UnsopportedOpperationException when
>> encountering a type that has a flexible array member.
>> As a result of that no class is written for the type, and when loading
>> the enclosing interface this throws a NoClassDefFoundError,
>> prohibiting use of the entire header interface.
>> We could mitigate this problem by emitting an undefined layout
>> reference instead of throwing an exception, which would only make the
>> type with the flexible array unusable, but still allow other things in
>> the same interface to be used.
>> Please review the following:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8218052
>> Webrev: http://cr.openjdk.java.net/~jvernee/panama/webrevs/8218052/webrev.00
>> Thanks,
>> Jorn