[foreign] RFR: 8225630: Tolerate unsupported type

[Henry Jen]

> On Jun 18, 2019, at 4:07 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> Hit 'send' too fast.
> 
> I guess how I feel about this is that we could:
> 
> 1)  use unresolved layouts, and some dummy carrier (Object, Void)
> 

I tried to use Void, but without special treatment, it will be unboxed to void and that’s not allowed by compiler.

> 2) have jextract generate struct interfaces for the unresolved types, so that you get a name - but have the layout of the interfaces be unresolved (so that you cannot allocate them)
> 

I try to use a single constant type, to avoid generate more Structs. The layout of UnknownType is meaningless is not used. However, the unresolved layout name actually shows up in the host layout is provided by LayoutUtils.

> This patch seems to do something in between.
> 

True, but I justify that UnknownType is better than Void to make it clear that here is an unknown type and will have some issue to use it.

Let me know if we prefer to go either approach, I don’t mind to change it.

Cheers,
Henry


> Maurizio
> 
> 
> On 18/06/2019 12:05, Maurizio Cimadamore wrote:
>> Hi,
>> can you explain why we need a new carrier for the unknown type? The new carrier layout is never generated by jextract - is that just to be able to generate 'some' carrier type?
>> 
>> Can we just use Object for that? Or Void?
>> 
>> Maurizio
>> 
>> On 12/06/2019 20:07, Henry Jen wrote:
>>> Hi,
>>> 
>>> Another short webrev[1] to make allow jextract go through when encounter unsupported types.
>>> 
>>> Basically for all unsupported type, we are going to generate a unresolved layout and use the UnknownType as carrier type. Reference UnknownType should cause failure at runtime, while the UnknownType class itself is an indication this function/setter/getter should not be used.
>>> 
>>> Cheers,
>>> Henry
>>> 
>>> [1] http://cr.openjdk.java.net/~henryjen/panama/8225630/0/webrev/