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

[Sundararajan Athijegannathan]

inline comment below..

On 26/05/18, 1:57 AM, Maurizio Cimadamore wrote:
>
> It looks better than before, but I think I spotted an issue; in 
> LayoutType:
>
> Group type = (Group) new DescriptorParser(Util.getNativeHeaderClass(carrier), nativeStruct.value()).parseLayout();
>
> This will always throw; unfortunately, the carrier passed here is a 
> @NativeStruct carrier, not a @NativeHeader one.

No. Util.getNativeHeaderClass walks through outer class locates 
@NativeHeader one.

> I forgot about this use case; this is another case of client-triggered 
> layout parsing; to be complete and consistent with your other changes, 
> the LayoutType.ofStruct would need to take an extra class argument, 
> but if you pull on the rope some more, you discover that 
> Scope.allocateStruct also need an argument... and we're quickly back 
> to square one - e.g. polluting lots of signatures.

I didn't find so. Only assumption here is that @NativeStruct classes are 
nested inside @NativeHeader classes - so that Util.getNativeHeader can 
locate the containing native header class. Unless we want to change the 
model of 'header' interface contains 'struct' interface as nested type, 
there is no issue.

-Sundar
>
> I think we need to think this through some more.
>
> Maurizio
>
> On 25/05/18 19:54, Sundararajan Athijegannathan wrote:
>> I agree. We can associate "header" interface Class object during 
>> parse time and thereby avoid passing LayoutResolver around - all the 
>> way down to ABI classes.
>>
>> Updated webrev: 
>> http://cr.openjdk.java.net/~sundar/redefinition_in_named_layouts/webrev.01/
>>
>> -Sundar
>>
>> On 25/05/18, 7:34 PM, Maurizio Cimadamore wrote:
>>> As discussed privately, I'm thorn about this:
>>>
>>> On the one had it makes the world safer and tidier.
>>>
>>> On the other hand, all clients dealing with layouts (including 
>>> clients external to the binder) have to manage Unresolved with 
>>> hazmat suit - which is a marked difference with where we were before.
>>>
>>> I wonder if a better compromise can be achieved by associating a 
>>> context to an unresolved layout at parse time?
>>>
>>> Maurizio
>>>
>>>
>>> On 25/05/18 13:48, Sundararajan Athijegannathan wrote:
>>>> If same name is used for two different (group) layouts, 
>>>> LayoutResolver should detect and report error. But different header 
>>>> file interfaces can use the same name.
>>>>
>>>> This is implemented by making LayoutResolver as a ClassValue rather 
>>>> than global.
>>>>
>>>> Webrev: 
>>>> http://cr.openjdk.java.net/~sundar/redefinition_in_named_layouts/webrev.00/
>>>>
>>>> Thanks,
>>>> -Sundar
>>>>
>>>
>