[foreign] RFR: 8220006: jextract is expected to output descriptor with explicit endianness

[Henry Jen]

As promised, update webrev[1] to update the golden templates. 

Cheers,
Henry


[1] http://cr.openjdk.java.net/~henryjen/panama/8220006/1/webrev/


> On Mar 4, 2019, at 8:28 AM, Henry Jen <henry.jen at oracle.com> wrote:
> 
> 
> 
>> On Mar 3, 2019, at 1:25 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>> 
>> 
>> On 02/03/2019 07:08, Henry Jen wrote:
>>> Follow up on the jextract fix to output the explicit endianness, please review this webrev[1]. Summary of the changes,
>>> 
>>> - Added a Address.withPointee(Descriptor), so that we can change the type of pointee,
>>> - A few helper methods to “localize” the descriptor in Runner.java.
>> 
>> I agree with the approach you followed in the test - at least I'm not too bothered by it.
>> 
>> But adding an API method to support the kind of rewriting you wanna do in the test seems a bit too much, and I'd prefer that to be a function in the test itself (we can add the API later if we feel we really need it, but it's better to keep API simple, at least at the start).
>> 
> 
> I hear you, I tried not too, but lacking a way to construct an address with a map of annotations.
> So I chose to add this as a cast operation or for-loop using withAnnotation. It’s also possible to add API to support construct with a map of annotations. 
> 
> 
>>> 
>>> Although this is not as comprehensive as gold master file, it’s effective as we have both approaches and they have to match, that helps identify issues either way.
>>> 
>>> However, if we don’t mind to add templates for different endianness, we can go ahead and do that.
>> I think medium term it would be better to just use the golden approach as for everything else - I'm not too bothered by using a short term trick to save some of the work, but note that we already have variants for windows, so if we get ARM, we'll likely have other variants with different endianness too. I think that's to be expected.
> 
> OK, I can switch to golden approach. That would eliminate the need to add API for now.
> 
>>> 
>>> Alternatively, perhaps we can add extra annotation in template classes to express different expected descriptor and read the right one from Runner. That would be good for keeping all form of descriptors in place and maybe easier to maintain.
>> 
>> I think we're in overthinking territory here. The use case is to make the test easier to maintain? But there are already sources for mismatches (the biggest offender being long 32 bits on Windows x64) which required different templates; so I think this is just not worth investing too much time on. Let's just assume that, in the worst case, endianness, size, and even set of functions, globals is going to differ wildly - so there will be different folders, one per ABI, and Runner will pick up the ones in the right folder (as it kind of happens now for Windows).
>> 
> 
> Agree, it’s just maintain extra copies or is it the difference will only appear in the ‘descriptor’ and we can maintain with one copy with variants.
> 
> Cheers,
> Henry
> 
>> Other than that, the jextract changes feel more robust than last time :-)
>> 
>> Maurizio
>> 
>>> 
>>> Thoughts?
>>> 
>>> Cheers,
>>> Henry
>>> 
>>> [1] http://cr.openjdk.java.net/~henryjen/panama/8220006/0/webrev/