Improve test for jextract and binder on different aspect of struct
Sundararajan Athijegannathan
sundararajan.athijegannathan at oracle.com
Mon Jul 16 16:44:13 UTC 2018
Nice test infrastructure change for round-trip testing of header files!
Minor: libStruct.c misses copyright comment.
+1
-Sundar
On 13/07/18, 10:41 AM, Henry Jen wrote:
> Hi,
>
> Please review the webrev[1] that adds tests for binder on top of existing struct.h test, and fixes for issues found during the process.
>
> Summary of change,
>
> - Add JtregJextract to run jextract as a driver, allow the result be used for the test case. See LibStructTest.java as an example. The options are pretty much as what jextract command line, except:
> - ‘-d' is ignored, as we default to have the classes into jtreg test.classes folder, so when we build the test, it can find the classes
> - A special terminator option ‘—‘, anything after ‘—‘ should be a header file with relative path from the test.src folder.
>
> - Added libStruct.c as first implementation allows binder to generate implementation classes. We will add more test cases over time, now it is a very minimal test.
>
> - Fix a couple LayoutResolver issues
> - Binder will throw ISE with a method pass a struct with nested anonymous record because cannot determine the size. The fundamental issue is that not all type are loaded as we only scan function signatures. The fix is to scan all inner classes for C record type at beginning.
> - An Unresolved layout could be resolved into another partial Layout type. All use cases we have expected a complete layout to be able to continue.
> - The origin annotation on the Unresolved in a partial layout is stripped, which I am not certain is what we designed for. As for the anonymous embed struct case, we still want the accessor annotation stick around.
>
> - Small modification of System V ABI implementation to experiment support of union and zero-length array(incomplete array)
>
> - The two resolve methods in LayoutResolver is changed to public for test case to access. It’s in a jdk.internal package, so I assume this is not too bad. I am open to suggestions on how to do it in a better way.
>
> [1] http://cr.openjdk.java.net/~henryjen/panama/libStruct/webrev/
>
> Cheers,
> Henry
More information about the panama-dev
mailing list