[foreign] RFR: 8225630: Tolerate unsupported type

[Maurizio Cimadamore]

On 18/06/2019 17:11, Henry Jen wrote:
>> 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.
I guess you mean in Util.makeType?
>
>> 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.

I get that; on the other hand, if you have a concrete carrier for the 
unknown entity there are also some advantages:

* the client can see a meaningful name in the IDE (note that the 
annotation contents will be not visible in the IDE)

* while instantiation of these structs fails - if somehow, a client 
provided an instantiation for the missing layout, instantiation could go 
ahead. If you have a single UnknownType with a single layout, there's no 
way to 'fill in the gaps' at a later stage.


>
>> 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.

I agree Unknown is better than Void - but I think having a synthetic 
carrier generated by jextract is probably the best approach in terms of 
flexibility - and probably not overly complex in term of implementation, 
I hope.

Maurizio

>
> 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/