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

[Maurizio Cimadamore]

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

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

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/