[foreign] RFR duplicates in named layouts have to be reported as error

[Maurizio Cimadamore]

Sorry - this is it:

http://cr.openjdk.java.net/~mcimadamore/panama/resolution_context/

Maurizio


On 04/06/18 03:24, Sundararajan Athijegannathan wrote:
>
> Sorry I was on vacation.  The link you provided seems to be the 
> initial named-layout implementation webrev. Will you please provide 
> the correct link?
>
> -Sundar
>
> On 28/05/18, 6:04 PM, Maurizio Cimadamore wrote:
>> Sorry, wrong webrev link, here's the correct one:
>>
>> http://cr.openjdk.java.net/~mcimadamore/panama/layout_resolver/
>>
>> Maurizio
>>
>>
>>
>> On 28/05/18 13:32, Maurizio Cimadamore wrote:
>>> Here's a stab at the current approach; I started with your patch and 
>>> tweaked in places.
>>>
>>> http://cr.openjdk.java.net/~mcimadamore/panama/panama-binder-v3.html
>>>
>>> I think the result is good; the problems you mention are resolved, 
>>> and all use cases are supported.
>>>
>>> Let me know what you think.
>>>
>>> Maurizio
>>>
>>>
>>> On 28/05/18 11:02, Maurizio Cimadamore wrote:
>>>>
>>>>
>>>> On 28/05/18 09:37, Maurizio Cimadamore wrote:
>>>>>
>>>>>
>>>>> On 28/05/18 07:39, Sundararajan Athijegannathan wrote:
>>>>>> Isolated Structs will work if there are no name definitions or 
>>>>>> references in its layout. If there are Unresolved name references 
>>>>>> in its layout, then there has to be a 'context' in which the 
>>>>>> names are defined/resolved. The context cannot be entire Java 
>>>>>> process as it currently is! Two issues with the current code: 
>>>>> I agree with all you say. The only thing I'm disagreeing with is 
>>>>> the fact that the context has to be the @NativeHeader annotation, 
>>>>> as that suggests an header-centric nature that was never intended 
>>>>> to be part of the design.
>>>>>
>>>>> Other, more explicit ways to define the context include an 
>>>>> explicit annotation which list all the classes where dependent 
>>>>> layout can be found. I think I'd like something like this better. 
>>>>> Example (names TBD):
>>>>>
>>>>> @NativeStruct("[$(b)](a)")
>>>>> @Friends(B.class)
>>>>> interface A {
>>>>>     B b();
>>>>> }
>>>>>
>>>>> @NativeStruct("[$(a)](b)")
>>>>> @Friends(A.class)
>>>>> interface B {
>>>>>     A a();
>>>>> }
>>>> Now that I have expressed this more explicitly, another idea 
>>>> emerged - what if we assumed that, if no annotation is provided, 
>>>> the context is the outermost class? That will work neutrally with 
>>>> both struct and header interfaces...
>>>>
>>>> Maurizio
>>>>>
>>>>>
>>>>> Maurizio
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>