Skip to content

Fix several issues in InstanceOfPatternMatch #489

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

Conversation

cortlepp
Copy link
Contributor

@cortlepp cortlepp commented Mar 26, 2025

What's changed?

  • always use the type in the cast for the new pattern and not the previously checked instanceof type.
  • when a variable name is already present in the source, don't search for duplicates and just take it as it is. Otherwise we would have to make unnecessary changes when the variable happens to be shadowing something else.
  • refuse to pattern-match non-wildcard generic types, as this cannot be checked due to type erasure.

What's your motivation?

Anything in particular you'd like reviewers to focus on?

I'll annotate some areas in the files themselves.

Anyone you would like to review specifically?

@greg-at-moderne

Have you considered any alternatives or workarounds?

Any additional context

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

- always set the clazz of a InstanceOfPatternMatch to the casted class (don't keep the one from the original type check)
- back off if the casted class is a non-wildcard generic
- adapt `Arrays#string()` test to new behavior
…es (openrewrite#483,openrewrite#484)

- doing so causes problems when the preexisting name shadows another variable, because our duplicate checking does not consider shadowing.
@github-project-automation github-project-automation bot moved this to In Progress in OpenRewrite Mar 26, 2025
null));
typeCastTypeTree.getType(),
null))
.withClazz(typeCastTypeTree.withPrefix(currentTypeTree.getPrefix()).withId(Tree.randomId()));
Copy link
Contributor Author

Choose a reason for hiding this comment

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

It seems superfluous or possibly even wrong that we have to pass the type to the Identifier and also set it as clazz on the J.InstanceOf. Maybe this could be avoided with Java template, but I was unsure how one would look for this case.

Copy link
Contributor

Choose a reason for hiding this comment

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

I assume you mean a reference to line 263 here.

Copy link
Contributor

Choose a reason for hiding this comment

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

It seems superfluous or possibly even wrong that we have to pass the type to the Identifier and also set it as clazz on the J.InstanceOf

Not sure I understand why you find it superfluous. All identifiers need a type (so that our LST is typed - i.e. all elements have proper type information attributed). And arguably o instanceof String s1 is a declaration of o Identifier and this needs type.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I guess I thought that by giving the identifier a type in line 263, this should determine the type for the entire expression and I should not have to set it again as the clazz. To me it seems like clazz should always be the same as the type passed in line 263, therefore I thought maybe I was using the class wrong or I misunderstood something generally.

@timtebeek timtebeek added the bug Something isn't working label Mar 26, 2025
Copy link
Member

@timtebeek timtebeek left a comment

Choose a reason for hiding this comment

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

Thanks a lot for the multiple fixes here @cortlepp ! @greg-at-moderne will have a look shortly and see if we can get this in before the release

Copy link
Contributor

@greg-at-moderne greg-at-moderne left a comment

Choose a reason for hiding this comment

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

I appreciate the great contribution. I consider it a piece of high quality work. Well tested, thoughtful and solving a few overlapping cases in one go!

There's one minor outstanding issue and I think we are good to merge.

(Also, I acknowledge your questions on some of the linked issues, I will get to them).

null));
typeCastTypeTree.getType(),
null))
.withClazz(typeCastTypeTree.withPrefix(currentTypeTree.getPrefix()).withId(Tree.randomId()));
Copy link
Contributor

Choose a reason for hiding this comment

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

I assume you mean a reference to line 263 here.

null));
typeCastTypeTree.getType(),
null))
.withClazz(typeCastTypeTree.withPrefix(currentTypeTree.getPrefix()).withId(Tree.randomId()));
Copy link
Contributor

Choose a reason for hiding this comment

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

It seems superfluous or possibly even wrong that we have to pass the type to the Identifier and also set it as clazz on the J.InstanceOf

Not sure I understand why you find it superfluous. All identifiers need a type (so that our LST is typed - i.e. all elements have proper type information attributed). And arguably o instanceof String s1 is a declaration of o Identifier and this needs type.

@github-project-automation github-project-automation bot moved this from In Progress to Ready to Review in OpenRewrite Mar 26, 2025
- no longer discover generic assignments if they aren't wildcards
- adapt `catTooSpecific` test to again cover the originally reported issue
@greg-at-moderne
Copy link
Contributor

Does it make sense to you?
Not trying to put any pressure or anything like this. Just wondering if you are blocked by anything here?

@cortlepp
Copy link
Contributor Author

cortlepp commented Apr 2, 2025

Hey, I'm currently on vacation until next week, I'll take a look at it as soon as I return. (Sorry I should've said something, I just forgot)

@greg-at-moderne
Copy link
Contributor

greg-at-moderne commented Apr 7, 2025

Not sure what's happening with Github, might be some glitch. I have clicked the button to approve CI run a few times already for this PR.

@cortlepp
Copy link
Contributor Author

cortlepp commented Apr 7, 2025

I think the run went through now (on your merge commit).

Copy link
Contributor

@greg-at-moderne greg-at-moderne left a comment

Choose a reason for hiding this comment

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

I am satisfied with this change. I appreciate the contribution.

@greg-at-moderne greg-at-moderne merged commit 3f49a05 into openrewrite:main Apr 7, 2025
2 checks passed
@github-project-automation github-project-automation bot moved this from Ready to Review to Done in OpenRewrite Apr 7, 2025
@arodionov
Copy link
Contributor

It looks like the current PR create an issue #528

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Archived in project
4 participants