Community
Participate
Working Groups
Copied from the forum for further discussion here: http://www.eclipse.org/forums/index.php/mv/msg/312484/824039/#msg_824039 Dani, Ayush, is this unexpected and unwanted behavior from your viewpoint? This information would be great to improve completion in general (not only our engines). > Hi, > > when triggering content assist on an argument of a MessageSend node as in > Composite c = new Composite(|<^Space>null, 0); > JavaContentAssistInvocationContext.getExpectedType() returns null. I'd > expected/would like to see that it returns the name of the only > parameter type that is possible in this context, Composite. > > Also, InternalCompletionContext.getExpectedTypesSignatures() returns > null. Is there any obvious reason why this is not supported - or does it > make sense to discuss this in more length in bugzilla? Looks fishy to me. Please open a bug. (In general, I think you should err on the side of opening a bug. It is OK if once in a while a bug is a false alarm.) - org.eclipse.jdt.internal.codeassist.CompletionEngine.computeExpectedTypes(ASTNode, ASTNode, Scope) is never called - As a result org.eclipse.jdt.internal.codeassist.InternalCompletionContext.setExpectedTypesSignatures(char[][]) is also never called.
Ayush, please follow up.
Any new insights?
(In reply to comment #2) > Any new insights? Sorry I didnt get time to look at this yet. However, from the top of my head I know that invoking content assist has a special meaning when done at the first location of an argument in a MessageSend, and that is to suggest the possible arguments for the method. Usually, I see only relevant proposals there, i.e. in the above example if i've declared 2 variables of type Composite, then content assist shows me those 2 variables, so there must be some kind of expected type calculation going on somewhere. I'll take a look at whether this is a bug.
(In reply to comment #3) > (In reply to comment #2) > > Any new insights? > > I'll take a look at whether this is a bug. Any news?
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > Any new insights? > > > > I'll take a look at whether this is a bug. > > Any news? Sorry once again. Too many things to do, this jumped off my radar. SO in this case, the completion parser returns a CompletionOnAllocationExpression node corresponding to new Composite(| , and there is no parent for this However, just like invoking content assist here - new Composite(x| it will be better to get a CompletionOnName node with its parent as the allocation expression. The expected type calculation already works fine for the latter case and will also work for the reported case with this strategy. I'm not sure I'll have time for this soon with the java 8 work in full steam. Marcel, will you be able to investigate a solution to guide the CompletionParser to produce the correct assist node? Thanks!
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.
