Skip to content

Add support for diamond operator in Groovy Parser #5783

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

Merged
merged 2 commits into from
Jul 22, 2025

Conversation

jevanlingen
Copy link
Contributor

@jevanlingen jevanlingen commented Jul 22, 2025

What's changed?

Diamond operators (<>) are now correctly supported when creating new generic instances like new ArrayList<>().

What's your motivation?

Previously, using new ArrayList<>() would incorrectly render as new ArrayList<>()>(), due to missing type inference information.

Any additional context

We did already support new HashMap<>(); this was only because the Groovy compiler happened to set the StaticTypesMarker.INFERRED_TYPE flag in that case. However, this flag is not consistently applied. This change ensures support even when the flag is missing by also checking if the generic type list is empty.

Interestingly, when the flag is present, the generic types are populated, which means we need to handle both cases: either rely on the flag or detect when the generics are empty.

Checklist

  • I've added unit tests to cover both positive and negative cases
  • I've read and applied the recipe conventions and best practices
  • I've used the IntelliJ IDEA auto-formatter on affected files

@@ -2516,15 +2516,10 @@ private <T extends TypeTree & Expression> T typeTree(@Nullable ClassNode classNo
&& classNode.getUnresolvedSuperClass().isUsingGenerics()
&& !classNode.getUnresolvedSuperClass().isGenericsPlaceHolder()
&& classNode.getGenericsTypes() == null;
if (isAnonymousClassWithGenericSuper) {
if (isAnonymousClassWithGenericSuper || (classNode.isUsingGenerics() && !classNode.isGenericsPlaceHolder())) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ℹ️ This change is just a small refactor. The implementation was completely the same, except for the argument of the visitTypeParameterizations call. I figured it's way easier to understand if we collapse these two branches into one.

@github-project-automation github-project-automation bot moved this from In Progress to Ready to Review in OpenRewrite Jul 22, 2025
@jevanlingen jevanlingen requested a review from timtebeek July 22, 2025 10:05
@jevanlingen jevanlingen merged commit 9cb3df0 into main Jul 22, 2025
2 checks passed
@jevanlingen jevanlingen deleted the groovy-parser-handle-diamond-operator branch July 22, 2025 10:20
@github-project-automation github-project-automation bot moved this from Ready to Review to Done in OpenRewrite Jul 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

3 participants