Bugzilla – Full Text Bug Listing
| Summary: | [1.7] Search for references to @PolymorphicSignature methods doesn't work | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Markus Keller <markus.kell.r> | ||||||
| Component: | Core | Assignee: | Satyam Kandula <satyam.kandula> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | daniel_megert, deepakazad, Olivier_Thomann, srikanth_sankaran | ||||||
| Version: | 3.7 | ||||||||
| Target Milestone: | 3.7.1 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 7 | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | 349486 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
|
Description
Markus Keller
Satyam, please investigate. Polymorphic methods are invoked using a different signature (according to the given arguments and assignment that can affect the return type). So I don't know exactly how we can work around this. The method definition is java.lang.invoke.MethodHandle.invokeExact(Object[]) returning an Object, but when invoked it is almost always a different signature. There are 2 kinds of reference searches that could be interesting for polymorphic methods: a) Given the declaration of the method, search for all references. This mode should be used when the user selects the declaration and then searches for references to the IMethod, or when he uses the fully-qualified name as search pattern string (optionally with the Object[] parameter type and the Object return type). In this mode, the search engine should not check the parameters or the return types when resolving references -- consider everything as a reference if the method name matches, the invocation is nonstatic, and the target type is a MethodHandle (or a subclass). b) Given a reference to the method, search for all other references that use exactly the same signature (parameter types & return type) as the given reference. The reference signature can either come from IMethod#getKey() (this is not yet completely implemented, see bug 349487 comment 4), or it can come from an explicit string pattern that contains the fully-qualified name of a polymorphic method and parameter/return types that don't match the declaration. I think (a) is important for 3.7.1, whereas (b) can also be dropped, i.e. all searches would only be based on the declaration. Search for a pattern of varargs has a problem. When user selects a method to search for a reference, the search pattern has a field which has vararg set and search does the right thing, whereas, when used as a pattern, the pattern doesn't recognize the varargs symbol (...) nor it uses []. I feel the search pattern should start recognizing the varargs symbol (...), rather than look for []. What do you think? (In reply to comment #3) > Search for a pattern of varargs has a problem. Yep, see bug 345621. For BETA_JAVA7, I don't think we should invest into the string pattern, since this is already broken in 3.7 for normal varargs methods. So I think the main focus for this bug in BETA_JAVA7 should be to support search for references to the IMethods. (In reply to comment #4) > (In reply to comment #3) > > Search for a pattern of varargs has a problem. > > Yep, see bug 345621. For BETA_JAVA7, I don't think we should invest into the > string pattern, since this is already broken in 3.7 for normal varargs methods. > So I think the main focus for this bug in BETA_JAVA7 should be to support > search for references to the IMethods. That could mean, fix for bug 349486 could become necessary for this. Will look at that first. Actually selecting the declaration of invokeExact() and searching works as of now. (In reply to comment #6) > Actually selecting the declaration of invokeExact() and searching works as of > now. Not for me. It finds some matches in the rt.jar, but it doesn't find the source references in the "Usage examples" code in a 1.7 project. The only source matches I see is when I put the "Usage examples" into a 1.5 project (finds inexact matches in the invocations with syntax errors). (In reply to comment #7) > (In reply to comment #6) > > Actually selecting the declaration of invokeExact() and searching works as of > > now. > > Not for me. It finds some matches in the rt.jar, but it doesn't find the source > references in the "Usage examples" code in a 1.7 project. > > The only source matches I see is when I put the "Usage examples" into a 1.5 > project (finds inexact matches in the invocations with syntax errors). I created a fresh project and am able to reproduce the problem now :(. The interesting point is if I delete this fresh project, I get back the references correctly from my old project and yes, when the fresh project was around, I didn't even get the references from my old project. Something weird. I will look at it. (In reply to comment #8) > I created a fresh project and am able to reproduce the problem now :(. The > interesting point is if I delete this fresh project, I get back the references > correctly from my old project and yes, when the fresh project was around, I > didn't even get the references from my old project. Something weird. I will > look at it. I figured out why it works sometimes. The PolymorphicSignature is not being set if the MethodHandle source file is used for resolving instead of the class file. Filed bug 350003 to take care of it. With the fix for bug 350003, search for references by selecting declaration of invokeExact(...) always fails :). Created attachment 198404 [details]
Proposed patch
With this patch search of references by selecting the declarations on invokeExact() works good.
The latest fix for 349488 fixes this problem. Will add the tests though. Created attachment 199131 [details]
Added test
Added JavaSearchBugsTests#testBug349683
(In reply to comment #2) > a) Given the declaration of the method, search for all references. This mode > should be used when the user selects the declaration and then searches for > references to the IMethod, or when he uses the fully-qualified name as search > pattern string (optionally with the Object[] parameter type and the Object > return type). This is fixed through the fix for bug 349488. > > b) Given a reference to the method, search for all other references that use > exactly the same signature (parameter types & return type) as the given > reference. The reference signature can either come from IMethod#getKey() (this > is not yet completely implemented, see bug 349487 comment 4), or it can come > from an explicit string pattern that contains the fully-qualified name of a > polymorphic method and parameter/return types that don't match the declaration. > > > I think (a) is important for 3.7.1, whereas (b) can also be dropped, i.e. all > searches would only be based on the declaration. I don't think this won't be exactly correct because the real method names could be different and hence no pointing of doing half job here and hence not doing this. Released the test in BETA_JAVA7 branch. |