[foreign-jextract] RFR: Represent typedef with Declaration.Variable instead of Declaration.Scoped

Maurizio Cimadamore mcimadamore at openjdk.java.net
Thu Apr 30 12:39:49 UTC 2020


On Thu, 30 Apr 2020 06:29:29 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> Currently jextract API only present typedef declaration for record types, and using Declaration.Scoped to do so.
> 
> This makes downstream tools like jextract impossible to generate more comprehensive type. For example, if the tool
> would like to create a carrier type for size_t with similar name, because we pass through that, this is impossible.
> This patch try to present typedef as Declaration.Variable with Kind TYPE. This will give us more transparency on
> dealing with typedef, and enable factoring an Declaration.Variable.TYPE from a Type.Delegated.TYPEDEF.
> This would also be useful when a tool collecting type dependencies and encounter anonymous type or types without
> declaration, this gave the tool a chance to inject an implicit typedef to associate a type with a proper name.
> There is one thing worth further discussion is that if we would like to consider generate array with typedef, currently
> the array element type won't be a Type.Delegated.TYPEDEF, but canonical type. The test case try to explain what should
> be expected for most use cases, if there is any possible way to use typedef, I'll try to add them.

I disagree (pretty strongly) with the direction proposed in this patch. Making a `typedef` a variable is a workaround.
Under no circumstances you can get a value out of a typedef - a typedef does not model a variable, and trying to bend
the API to do so is, IMHO, wrong.

To me the big issue is that a typedef declaration, as it stands, is only good to wrap a declaration. But the solution I
think, would be to have a more explicit `TypeDef` declaration tree, which has a name and a type (where the type can be
a `Declared`, if need be).

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/137


More information about the panama-dev mailing list