Community
Participate
Working Groups
Content assist proposes 'out - Object', which is incorrect ------------------------------------------------------ void foo(String s) { switch (s) { case "abc": System.out.println("abcd"); break; case "xyz": System.out.println("xyz"); break; case <Ctrl+space> default: System.out.println("oops"); break; } } ------------------------------------------------------
This is expected behaviour, since we proposed all the unresolved names also in the list of proposals, to make sure that when one has used a variable previously but not declared it, one can still get a proposal for it. In this case out is an unresolved name.
Reopening for further investigation. We need to understand why 'out' is returned. System.out should resolve so it should not be considered as an unresolved reference. Targeting RC1 for the investigation. This doesn't mean this will be fixed. It all depends on the outcome of the investigation.
Actually, the name references are all found by parsing the lines of code starting from the enclosing method to the point where assist is invoked. org.eclipse.jdt.internal.codeassist.complete.CompletionParser.getUnspecifiedReference() is the one that records all the names encountered during this parsing. See bug 162865 for details. So even though the intention was to propose unresolved references, we ended up proposing all name references. This is why 'out' also ends up being proposed, since the parsing has no notion of whats resolved and whats not. The one thing we can try doing is to cache the unresolved variables that were found during the resolution of the compilation unit just before the call to CompletionEngine.complete(..) (i.e. at the point we report the "*cannot be resolved" errors), and save this list in the enclosing method scope. Then inside CompletionEngine.complete(..) , query the scope and add all these unresolved names as proposals. This way, we will skip resolved names such as 'out' below but still propose unresolved variables such as 'var': void foo(String s) { var = 1; switch (s) { case "xyz": System.out.println("xyz"); break; case <Ctrl+space> default: System.out.println("oops"); break; } } We can also leave it as it is coz I don't think the proposal is such a distraction. It has a low priority and doesn't really appear on top of the list. The above approach, if done will make the code resolution need more memory space in situations other than content assist as well, since the unresolved variables will always be cached. It may improve performance of content assist though, since the extra parsing won't be required. If this is to be attempted, this will have to be moved to 3.8. Olivier, let me know what you think.
(In reply to comment #3) > The one thing we can try doing is to cache the unresolved variables that were > found during the resolution of the compilation unit just before the call to > CompletionEngine.complete(..) (i.e. at the point we report the "*cannot be > resolved" errors), and save this list in the enclosing method scope. Then > inside CompletionEngine.complete(..) , query the scope and add all these > unresolved names as proposals. This way, we will skip resolved names such as > 'out' below but still propose unresolved variables such as 'var': Sounds good. Since we don't have that many unresolved references I don't expect that list to be very big and therefore I don't think the cost in memory is that high. > If this is to be attempted, this will have to be moved to 3.8. Olivier, let me > know what you think. Definitely for 3.8 given the analysis of the problem.
Moving it out of 3.8 plan for now. If we manage to find cycles, we will reconsider.
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.
