[foreign] RFR 8215211: cleanup JType/TypeDIctionary

[Sundararajan Athijegannathan]

Very nice! I built & tested the patch on Mac and also ran our platform 
specific samples (on mac). All fine.

One question: why is the EnumTree part in typedef handler is removed?

Other than that +1

-Sundar

On 11/12/18, 9:32 PM, Maurizio Cimadamore wrote:
> Hi,
> please review this jextract patch:
>
> http://cr.openjdk.java.net/~mcimadamore/panama/8215211_v2/
>
> The goal is to simplify the JType hierarchy and the TypeDictionary 
> class. JType is currently a very rich hierarchy that is capable of 
> modeling basically any clang type/cursor. In a way, JType is 
> overlapping a lot with the recently added jextract tree 
> representation; it feels like JType can be greatly simplified, and we 
> can just rely on trees for structural info.
>
> Simplifying the JType hierarchy has many benefits - in the patch you 
> will notice that we no longer need a lot of instance tests and casts.
>
> The second issue is with TypeDictionary, whose lookup/define logic is 
> scattered across TypeDictionary and HeaderFile::define. There's also a 
> very complex lookup scheme which starts from TypeDictionary::lookup 
> and then ends up in Context then back to HeaderFile::define. This is 
> all very hard to follow.
>
> I've now centralized all type resolution logic in TypeDictionary, 
> which now features two functions: lookup and enterIfAbsent, which 
> internally share the same 'getInternal'. TypeDictionary will simply 
> create a JType from a clang Type, and the only thing a TypeDictionary 
> has to keep track of, is the use of the anonymous function types 
> created during the 'enter' phase. Note that such enter phase has now 
> been moved into a proper tree visitor.
>
> This simplify things quite a bit, to the point that 
> AsmCodeFactory::addType becomes a simple visitor call. I think more 
> rounds of cleanup are possible, but, to get there, we need to simplify 
> the logic of Context/HeaderFile::processTree, which requires having a 
> more precise mapping between clang compilation units and jextract 
> trees. For instance, we currently parse everything into the same 
> 'header tree', even if we end up generating multiple classes; 
> secondly, we sorely miss a CallbackTree, so we have to do a lot of 
> gymnastic in order to understand which classfiles need to be generated 
> for functional interfaces.
>
> Note: I seem to recall that function pointer typedef should emit, a 
> named functional interface matching the name of the typedef. But the I 
> noted that this is not the way things work in the current impl, so I 
> did not bother too much with that (but I can address that if required, 
> although doing so will cause breakages in tests, so I'd prefer to do 
> that separately).
>
> Cheers
> Maurizio
>