Community
Participate
Working Groups
Search for a method declaration of Worker.run() returns some incorrect anonymous classes as potential matches. To reproduce: 1. Open a fresh workspace 2. Create a java project 3. Use a JDK attached to source code 4. Search for method declarations of Worker.run() You will see many potential matches for anonymous classes. These could be probably avoided.
While reading some class files, an Abortcompilation exception is getting thrown and subsequent source files are not getting parsed to resolve some bindings. As the bindings were not resolved, search engine is returning those matches as potential matches. This happens for only anonymous classes because abort happens at the stage of parsing method statements and their resolution.
Created attachment 180648 [details] Proposed patch The exception happens while parsing types which use the enclosing method's type parameters. For finding the signatures we do look at the enclosing type's parameters but not methods. In this patch, while calculating the type's parameters, I have made the type take the enclosing method's type parameter. With this patch, I don't have any potential matches with my workspace.
Srikanth, Please review.
The source of this bug seems to impact refactoring too as reported in the second part of bug 293861 comment 62.
(In reply to comment #3) > Srikanth, Please review. The patch as it is fails to apply. Could you regenerate after synching with HEAD and repost for review ? Thanks!
Created attachment 181811 [details] Proposed patch syncing with HEAD Srikanth, I have regenerated the patch. Please review.
My sincere apologies, this has been in my queue for a long time. Everytime I plan to get to it, I get overwhelmed by half a dozen of those 1.4/1.5 defects to work on. I'll prioritize it and get this review early next week -- Thanks.
I am not quite sure manipulating the arity of the local/anonymous type to make it include the type parameters of the enclosing method is the right way to go. Given these are local/anonymous types and given further that these are binary types we are talking about, it may not be as risky to munge things this way. Nevertheless, akin to being able to query the type parameters of an enclosing type in the case of inner type, I would recommend we investigate and see if a cleaner approach may be possible.
I get your point. However, we don't store the enclosing method information anywhere except from the class file Object itself( ClassFileReader ) :(. We do need this information at LookupEnvironment#getTypeFromTypeSignature() where it could get costly to access the class file object. One proper way could be is to create an object like LocalTypeBinding which extends BinaryBinding and has enclosing method, but it is probably not necessary except for this problem. What do you think?
(In reply to comment #9) > I get your point. However, we don't store the enclosing method information > anywhere except from the class file Object itself( ClassFileReader ) :(. We do > need this information at LookupEnvironment#getTypeFromTypeSignature() where it > could get costly to access the class file object. One proper way could be is to > create an object like LocalTypeBinding which extends BinaryBinding and has > enclosing method, but it is probably not necessary except for this problem. > What do you think? Thanks for the explanation Satyam, under the circumstances, I suggest you proceed with the approach you have.
Thank you Srikanth. Released this on HEAD
*** Bug 250958 has been marked as a duplicate of this bug. ***
Verified for 3.7M5 using I20110124-1800
