Community
Participate
Working Groups
Created attachment 194065 [details] test project Occurs in 3.7 M6 In the attached test project, in the type TestType, if the cursor is placed inside the first quote of "element", the CompletionContext accessible from the completion proposal computer has token start and end of 0, rather than the actual text location. This seems to be wholly caused by the presence of the package-info.java file. If this file is removed, the CompletionContext has the proper start and end tokens. To determine the start and end token, you can simply place a breakpoint in any computeCompletionProposals(ContentAssistInvocationTarget, IProgressMonitor) method in any appropriate completion proposal computer and look at the context object. I put mine at line 206 in JavaCompletionProposalComputer and inspected the javaContext object. This is causing problems because it causes completion inserts to be placed at the beginning of the document rather than where the cursor is.
Can reproduce in I20110425-1800. Please verify whether this is a regression compared to 3.6.2. If so, please fix for 3.7.
Ayush, please follow up - TIA.
I could not validate your claim about the source start and end, because the 'context' object in the computeCompletionProposals(..) method does not contain this info (Let me know if this info is indirectly available through it though, I may have missed that out). However, I do see that content assist throws an exception when i try to invoke it at @XmlElement(<CTRL-SPACE>name = "element"), and this only happens in the presence of the pacakge-info.java file. I'll investigate.
(In reply to comment #3) > I could not validate your claim about the source start and end, because the > 'context' object in the computeCompletionProposals(..) method does not contain > this info (Let me know if this info is indirectly available through it though, > I may have missed that out). It does for me. Try adding a breakpoint to JavaContentAssistInvocationContext.getCoreContext().
Btw, this is a regression over 3.6.2 and has been exposed by the fix for bug 337868, since we did not get a type for pakage-info.java earlier, but now we do.
Created attachment 194161 [details] patch under test This patch fixes the problem. Testing.
In fact, I could see that content assist behaves differently at many places where the assist node parent is required to compute the expected type, build context, etc. , when the package-info.java is present. A similar case is public class TestType { String abc = "hi"; String element = <CTRL-SPC>; } We should get abc as the first proposal but we don't, since the expected type is not correctly calculated in the absence of assist node parent. With the above patch, the behaviour will return to normal
Created attachment 194242 [details] proposed fix v1.0 + regression tests The patch just makes sure that the type created for package-info.java for the compiler is not accepted by the requestor during completion i.e. the CompletionEngine. The problem without the patch is that the call to org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.buildTypeBindings(..) at CompletionEngine.java:1845 finds the package-info as a type from the NameEnvironment and at LookupEnvironment.java:142, this dummy type is accepted by the CompletionEngine(Engine), which leads to resetting of the parser and also the assistNodeParent ( see org.eclipse.jdt.internal.codeassist.impl.Engine.accept(ICompilationUnit, AccessRestriction)). So by the time org.eclipse.jdt.internal.codeassist.CompletionEngine.complete(ASTNode, ASTNode, ASTNode, CompilationUnitDeclaration, Binding, Scope, boolean) is reached, the assistNode has been resetted to null and the parser is parsing package-info.java The patch alleviates these problems. Also, debugging ahead to org.eclipse.jdt.ui.text.java.JavaContentAssistInvocationContext.getCoreContext() now shows the correct token start and end. All tests pass
Created attachment 194243 [details] proposed fix v1.0 complete + regression tests The above patch missed a few files
Srikanth, please review for RC1. Thanks!
Deepak confirmed that all UI tests pass.
Patch looks good. One suggestion is to refer to the bug 337868 in the comment for the new method.
Released in HEAD for 3.7RC1.
Verified for 3.7 RC1 using build I20110511-0800
