Fix new generics with spefic modules #1122
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| for (ImClass c : prog.getClasses()) { | ||
| c.getFields().removeIf(f -> isGenericType(f.getType())); |
There was a problem hiding this comment.
After specialization we still retain the original generic static fields in prog.getGlobals(): removeGenericConstructs now only strips generic functions/methods/classes and generic fields, but no longer removes the globals identified in identifyGenericGlobals. Because collectGenericUsages.visit(ImVar) explicitly skips globals, those variables keep their ImTypeVarRefs and nothing rewrites or replaces them. Any generic class/module with static thistype fields (e.g. the new linked list module) will therefore leave an unspecialized global definition in the final program, reintroducing type variables into the backend output.
Useful? React with 👍 / 👎.
No description provided.