Community
Participate
Working Groups
This is a follow up of https://bugs.eclipse.org/bugs/show_bug.cgi?id=402081. In that CR, I have actually added basic support for code completion at reference expressions past the :: We basically offer any and all methods that match the prefix, completely ignoring the target type. We should use the target type to weed out methods that won't be applicable.
*** Bug 443710 has been marked as a duplicate of this bug. ***
Moving Out of 4.5
The exact target type is often unknown in incomplete code, so we cannot be perfect here. But at least the method reference content assist proposals with a structurally matching signature type should be more relevant than the other proposals. Example: new Random(0).ints(f, 'a', 'z' + 1).collect(StringBuilder::new, null, null); The API IntStream#collect(Supplier<R>, ObjIntConsumer<R>, BiConsumer<R, R>) tells that the first parameter requires a method reference for a static method or constructor that takes no argument and that returns an R. I.e. after "StringBuilder::", the only structurally applicable proposal is the "new" keyword. This should be on first place. The second parameter of collect(.., ObjIntConsumer<R>, ..) requires a method ref that matches one of these signatures: (a) instance method * *(int) (b) static method * *(R, int) We don't know the R, and the int may also match Integer or Object or even Object..., but even without knowing the exact signature, we can: - rule out methods like capacity(), delete(int, int), etc. - prefer append(int) over append(boolean) and the like
If completing the last missing piece in an expression-to-be-type-inferred, then we _could_ perform type inference for each potential proposal, to filter/rank low those that would yield type errors.
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.
At least the example from comment 3 could be fixable with recent improvements in this area.
