Community
Participate
Working Groups
It's a really simple bug: The Sysout + ctrl + space snippet not working on lambda function.
I see one case where it doesn't work, but would like to get your use case just to be sure. For e.g. in the following code, there's one place where the completion works and another where it doesn't: public abstract class CycleViewHandler extends CycleBaseHandler { @Override protected void addItems(Table table, WorkbenchPage page) { List<MPart> parts = null; parts.stream().sorted((firstPart, secondPart) -> { syso| // no completion Long firstPartActivationTime = (Long) firstPart.getTransientData() .getOrDefault(PartServiceImpl.PART_ACTIVATION_TIME, Long.MIN_VALUE); Long secondPartActivationTime = (Long) secondPart.getTransientData() .getOrDefault(PartServiceImpl.PART_ACTIVATION_TIME, Long.MIN_VALUE); return -(firstPartActivationTime.compareTo(secondPartActivationTime)); }).forEach(part -> { syso| // completion works if (true) { if (true) { IEditorPart activeEditor = page.getActiveEditor(); if (activeEditor == null) { } } } }); } }
Shure, in my case is the following code: carrinhos.stream().map(c -> c.getValorTotal()).forEach(e -> sysout); // does't work
Shure, in my case is the following code: carrinhos.stream().map(c -> c.getValorTotal()).forEach(e -> sysout); // does't work (In reply to Jay Arthanareeswaran from comment #1) > I see one case where it doesn't work, but would like to get your use case > just to be sure. For e.g. in the following code, there's one place where the > completion works and another where it doesn't: > > public abstract class CycleViewHandler extends CycleBaseHandler { > @Override > protected void addItems(Table table, WorkbenchPage page) { > List<MPart> parts = null; > > parts.stream().sorted((firstPart, secondPart) -> { > syso| // no completion > Long firstPartActivationTime = (Long) firstPart.getTransientData() > .getOrDefault(PartServiceImpl.PART_ACTIVATION_TIME, Long.MIN_VALUE); > Long secondPartActivationTime = (Long) secondPart.getTransientData() > .getOrDefault(PartServiceImpl.PART_ACTIVATION_TIME, Long.MIN_VALUE); > return -(firstPartActivationTime.compareTo(secondPartActivationTime)); > }).forEach(part -> { > syso| // completion works > if (true) { > if (true) { > IEditorPart activeEditor = page.getActiveEditor(); > if (activeEditor == null) { > } > } > } > }); > } > }
(In reply to Renan Pallin from comment #2) > Shure, in my case is the following code: > > carrinhos.stream().map(c -> c.getValorTotal()).forEach(e -> sysout); // > does't work Can you please provide the test code that compiles?
(In reply to Renan Pallin from comment #2) > Shure, in my case is the following code: > > carrinhos.stream().map(c -> c.getValorTotal()).forEach(e -> sysout); // > does't work Renan, can you confirm if the problem is only for syso template and it works for other cases of completion? For e.g., the following works for me: carrinhos.stream().map((x)-> (String) x).forEach( e-> e.toS));
The syso template not being proposed/completed appears to be lack of correct completion context information from JDT Core. I believe the reason is the following code in CompletionEngine#buildTokenLocationContext(). f (referenceContext instanceof LambdaExpression) { LambdaExpression expression = (LambdaExpression)referenceContext; if (expression.body().sourceStart <= astNode.sourceStart && astNode.sourceEnd <= expression.body().sourceEnd) { // completion is inside a method body if (astNodeParent == null && astNode instanceof CompletionOnSingleNameReference && !((CompletionOnSingleNameReference)astNode).isPrecededByModifiers) { context.setTokenLocation(CompletionContext.TL_STATEMENT_START); } } The check astNodeParent == null returns false for completions invoked inside lambda body. But I believe this is the correct behavior. In the testcase mentioned in comment #3, the only possible completions are expressions that can return a value. So, the syso doesn't make sense at all. I have also verified that if the lambda has a block i.e.. {}, and we try to invoke the completion inside the block, then everything is fine. I am inclined to close this report unless there is any other applicable testcase. BTW, I went back to the codes I had posted in comment #1 and found them to be working. Not sure what was happening before.
Hi, sorry taking so long to answer, I'm working and finishing college and my free time is really short at the moment. In my opinion - and in the way I write code -, therefore the sysout rarely stays in the final code, is really great for me to use while I'm developping, testing, finding bugs and in some logs. I think this snippet should work in this case, also he work inside {}, in my point of view shold work whitout the {} in the same way. Maybe is too late to provide the whole code that compile, was a test for a job I make xD Thanks for the attention, man, I'm here if you need me and in the future, I'd like to contribute to Eclipse too =) Renan (In reply to Jay Arthanareeswaran from comment #6) > The syso template not being proposed/completed appears to be lack of correct > completion context information from JDT Core. I believe the reason is the > following code in CompletionEngine#buildTokenLocationContext(). > > f (referenceContext instanceof LambdaExpression) { > LambdaExpression expression = (LambdaExpression)referenceContext; > if (expression.body().sourceStart <= astNode.sourceStart && > astNode.sourceEnd <= expression.body().sourceEnd) { > // completion is inside a method body > if (astNodeParent == null && > astNode instanceof CompletionOnSingleNameReference && > !((CompletionOnSingleNameReference)astNode).isPrecededByModifiers) { > context.setTokenLocation(CompletionContext.TL_STATEMENT_START); > } > } > > The check astNodeParent == null returns false for completions invoked inside > lambda body. But I believe this is the correct behavior. In the testcase > mentioned in comment #3, the only possible completions are expressions that > can return a value. So, the syso doesn't make sense at all. I have also > verified that if the lambda has a block i.e.. {}, and we try to invoke the > completion inside the block, then everything is fine. > > I am inclined to close this report unless there is any other applicable > testcase. > > BTW, I went back to the codes I had posted in comment #1 and found them to > be working. Not sure what was happening before.
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.
