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

[Sundararajan Athijegannathan]

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