New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8244244: Better representing typedef in jextract API #137
Conversation
👋 Welcome back henryjen! A progress list of the required criteria for merging this PR into |
To avoid this situation, create a new branch for your changes and reset the
Then proceed to create a new pull request with |
Webrevs
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
While I agree with your statement, the Declaration.Variable API doesn't present a value(), only Constant has a value(). In a sense, type() is the value of a Type declaration.
As current Declaration.Variable stands, it's perfect, with name(), type() and kind(). We can either create a different interface, or rename to something else if that helps. |
Variable is perfect in the sense that it has the right structure. But it's not at all what a typdef is! Imagine I write a visitor for the declaration API: if I see vistVariable and I'd expect to see a global, or a struct field, I would now have to defend against typedefs? From a logical point of view a typedef has nothing to do with a variable declaration, so a new |
Mailing list message from Henry Jen on panama-dev: On Apr 30, 2020, at 9:53 AM, Maurizio Cimadamore <mcimadamore at openjdk.java.net> wrote:
Yes.
Regarding the defense, isn?t that the case already when we suppose to check kind() to do proper action? However, I understand that by ?Variable?, we maybe thinking a classification that you will need to generate a getter/setter for its value, which won?t be the case for typedefs, but it is somewhat a stretch for PARAMETER as well.
Sure. We should add a new Visitor method as well? Cheers, |
I think so. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are many tests which still depend on Variable.kind.TYPE - how can they pass, given that the code never seem to create such vars?
src/jdk.incubator.jextract/share/classes/jdk/incubator/jextract/Declaration.java
Show resolved
Hide resolved
src/jdk.incubator.jextract/share/classes/jdk/incubator/jextract/Declaration.java
Outdated
Show resolved
Hide resolved
src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/DeclarationImpl.java
Outdated
Show resolved
Hide resolved
I didn't realizes TestAnonymousDecl.java was in there. That is something from another branch and have dependency on other part not included in this patch. I must added by accident. Only TestTypedef.java is suppose to be added. Strangely, I thought that should be caught by make run-test-jdk_jextract? |
@slowhog This change now passes all automated pre-integration checks, type
Since the source branch of this PR was last updated there have been 130 commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid automatic rebasing, please merge ➡️ To integrate this PR with the above commit message to the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Neat work, thanks
/integrate |
@slowhog The following commits have been pushed to foreign-jextract since your change was applied:
Your commit was automatically rebased without conflicts. Pushed as commit 067ccd7. |
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.
Progress
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/panama-foreign pull/137/head:pull/137
$ git checkout pull/137