[foreign] RFR: 8225630: Tolerate unsupported type

[Henry Jen]

> On Jun 18, 2019, at 9:26 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 
> 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?

Nope, this is just my dumb mistake of using JType.Void, I should use JType.of(Void.class) instead. :)

>> 
>>> 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 is optimistic thinking. However, if such mechanism available, I assume it has to link via the Unresolved layout, not carrier type class name? Also given that UnknownType is an interface, I suppose a Class can implement the interface and provide concrete layout.

Anyhow, for this to work, the layout must be supported by SystemABI.

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

I tried before, but quickly gave up as it’s not simply just add into TypeDictionary. I dig into this more seriously today , turns out it’s pretty complicate.

Basically, to generate a carrier type for a give clang Type, we need a Tree which was constructed from Cursor. However, for types like Vector, it won’t have a proper Cursor as the Type.getDeclarationCursor() would be NoDeclFound. That is, given a Type t, t.getDeclarationCursor().type() is not necessary give back t.

Also we cannot simply use the top-level declaration cursor that gave us the type, as that is not necessary the proper origin of the type.

I can continue to work on this, but I don’t think it’s necessary for now. So I would suggest we choose to use either Void or UnknownType, and fix this when we working on strategy for plugin unresolved layout.

Cheers,
Henry


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