[foreign-jextract] RFR 8236434: Initial jextract API implementation

[Maurizio Cimadamore]

Hi,
here's the initial webrev for the jextract API:

http://cr.openjdk.java.net/~mcimadamore/panama/8236434/

And here's a link to the javadoc for said API:

http://cr.openjdk.java.net/~mcimadamore/panama/jextract_javadoc

Summary:

* most of the configuration changes come from the "foreign" branch - 
that is, when building the new "foreign-jextract" branch you will need 
to specify an LLVM install (e.g. --with-libclang); I've removed few 
things that seemed to be unused, but most of the stuff is really the 
same - in principle I could have done w/o - but then it's really hard to 
use and test the API.

* In the implementation code, you will find a Java port of libclang - 
this port has been fully written using the stuff in the foreign-abi 
branch (hence, method handles and var handles). The lowest layer of this 
API is contained in the 'libclang' folder and has been autogenerated for 
the most part. In other words, there's not a single line of JNI code in 
here.

* It's interesting to note how - despite the many native calls in used 
in this port, only _one_ required breaking into privileged mode, and 
into ForeignUnsafe. I think that's pretty good!

* I've paid extra attention when using layout constants - more 
specifically, since libclang already tries to be portable and to define 
things so that they have same sizes on all platforms (e.g. a long in 
Linux becomes a 'long long' in Windows), I've defined a bunch of 
size-specific ABI layout constants in ClangLayouts, and then used these 
everywhere in the library port. In the library implementation there are 
few places where we need to use real ABI-dependent layouts (when 
creating a Type object from a clang type), so you'll see some uses of 
another set of constants defined inside LayoutUtils. Hopefully, all this 
gymnastic should result in something that works across all ABIs.

* I've added a very simple smoke test - I know we need to do more here, 
but I think it's better to start somewhere. Besides, this test should 
provide a useful basis to, eventually, build a more general framework to 
validate the result of the jextract API parsing.

* There's no minimal jextract as of yet - since this changeset is 
already very big, I think it's better to first push the API, and then 
review the extractor code separately.

Cheers
Maurizio