More new generic improvements #1131
Conversation
Frotty
commented
Dec 22, 2025
Frotty
commented
- reject unspecified static new generic usage
- fix generics with monomorphism
- add a big test suite
|
@codex review |
![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".
...stscript/src/main/java/de/peeeq/wurstscript/translation/imtranslation/EliminateGenerics.java
Outdated
Show resolved
Hide resolved
|
@codex review |
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".
| if (isUsedAsReceiverInExprMember(e) && isNewGenericTypeDef(def)) { | ||
| Element parent = e.getParent(); | ||
| parent.addError( | ||
| "Cannot access members via generic type '" + def.getName() + "' without specialization.\n" | ||
| + "New generics (<T:>) require a concrete specialization; use an instance receiver instead." |
There was a problem hiding this comment.
The new validation rejects all static member access on a new-generic type, because it only checks isNewGenericTypeDef(def) and never verifies whether the reference is already specialized. That means valid code like Foo<int>.bar (explicit type args) will still hit this error path, even though the message says “without specialization” and the rest of the pipeline now tries to specialize generic statics. Consider gating the error on missing type arguments (e.g., wtns.getTypeParameters().isEmpty() or equivalent) so specialized static access remains legal.
Useful? React with 👍 / 👎.
