-
-
Notifications
You must be signed in to change notification settings - Fork 352
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
fix(ImportCleaner): resolve imports of parent types #4353
Conversation
@slarse @MartinWitt @I-Al-Istannen can you please look at it? |
I think this breaks the following class (import is removed and import java.util.Map.Entry;
class Hello {
public void hey() {
Entry<String, String> f = null;
}
} |
Thanks for pointing it out. I am looking into it. |
You were right about it. I also added a condition which would check if the subtype is present. However, the reference to subtype here is |
thanks @algomaster99 |
@algomaster99 I don't think that's a good idea. What you're suggesting is some form of partial comparison, i.e. not equality. |
I thought it would be beneficial in comparing references. For example, in this case, I needed to compare two references - reference to an import and a field's type. I just wanted to skip comparison for |
I get the use case, but that's not equality, it's a different kind of comparison. So I don't think it's appropriate for the Put simply, a reference with type arguments is not equal to a reference without type arguments, even if the referenced type is the same. |
Reference: ASSERT-KTH/sorald#598
Type
B
inA.B x = new A.B()
was not being resolved toimport somePackage.A
even though this import statement was present in the compilation unit.I apologise for the bad test case. I wasn't able to reproduce the bug in a smaller test file. The reason was that whenever it used to visit
B
inA.B x
, the visit was ended due to this condition. However, this line didn't interfere with the original test resource which brought about this bug.