Community
Participate
Working Groups
ICodeAssist#codeSelect should return lambda IMethod, not the overridden SAM of the functional interface. Once bug 429812 is fixed, the Javadoc hover should find the doc from the overridden method (already works for signatures that only contain primitive types).
Markus, Can this wait until later ? For one thing, there is no IJavaElement for method references - they will have to return the sam binding anyway. For lambdas also, could you cite what exactly breaks by having the sam binding returned ? I agree the signatures should be fixed (https://bugs.eclipse.org/bugs/show_bug.cgi?id=429812) immediately. For starters, I took the "these are expressions" view - At this point, it looks to me that we should get the basic hover working for GA and look at all else post GA, but soon. If you think it is a must, we can document at the right place that this is what these APIs are doing at the moment, but this is subject to change - I personally think it is not necessary.
(In reply to Srikanth Sankaran from comment #1) > Markus, Can this wait until later ? For one thing, there is no IJavaElement > for method references - they will have to return the sam binding anyway. Yes, I think it's safer to wait until after GA. Javadoc of codeSelect(..) says: "Returns the Java elements corresponding to the given selected text". We use this element as the basis for many navigation/hover operations. E.g. the Open Implementation hyperlink should not appear for a lambda. Ctrl+T should also start on the lambda. And hovers should show the resolved type information for the lambda method, not generic type variables from the SAM. Method references are a problem. So far, we said it's overkill to add IMethod elements for them. I need to think a bit more about that.
(In reply to Markus Keller from comment #2) > Method references are a problem. Nope, no problem here. In contrast to lambdas, method references don't add a new method implementation, so we don't need an element for them. The interesting properties of a method reference are - the concrete referenced method (i.e. the right declaring class and the right overloading), and - the inferred type arguments. => We're in the same position as with ordinary method invocations, where codeSelect already returns an IMethod that contains this resolved information.
There is no owner for code assist as of now
I will give it a try, but no promise on timeline yet.
No progress on this. Will look at this during 4.6.
No progress yet and unlikely to get time during 4.6. Moving out.
Bulk move out of 4.8
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
