Bug 547022 - [code assist] no proposals in switch inside a lambda expression
Summary: [code assist] no proposals in switch inside a lambda expression
Status: NEW
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 4.9   Edit
Hardware: PC Windows 10
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords:
Depends on:
Blocks:
 
Reported: 2019-05-06 16:26 EDT by N247S - CLA
Modified: 2023-05-26 15:26 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description N247S - CLA 2019-05-06 16:26:28 EDT
I find that auto-completion with JDT is doing weird stuff with nested classes (both Functional implementations and solid implementations). I am not sure how many are connected, but I'll report them one by one.

This one is 100% reproducable with the following MCVE:

public class BugTest
{
	public void test()
	{
		this.someMethod(O -> {
			switch(5)
			{
				// pos2
				case 1:
					// pos1
				break;
				// pos3
			}
		});
	}
	
	public void someMethod(Consumer<Object> consumer){ /* no-op */}
}


In the above case we should be able to use the autocomplete at the marked position [pos1], yet it does not yield any result. I only managed to get the user-templates working.

- The enum in the switch-statement can be of any type.
- At pos2 and pos3 the autocomplete is working correctly.
Comment 1 Dani Megert CLA 2019-05-07 06:00:56 EDT
(In reply to N247S - from comment #0)
> I find that auto-completion with JDT is doing weird stuff with nested
> classes (both Functional implementations and solid implementations). I am
> not sure how many are connected, but I'll report them one by one.
> 
> This one is 100% reproducable with the following MCVE:
> 
> public class BugTest
> {
> 	public void test()
> 	{
> 		this.someMethod(O -> {
> 			switch(5)
> 			{
> 				// pos2
> 				case 1:
> 					// pos1
> 				break;
> 				// pos3
> 			}
> 		});
> 	}
> 	
> 	public void someMethod(Consumer<Object> consumer){ /* no-op */}
> }
This snippet does not compile. Please attach a self-contained snippet.
Comment 2 Dani Megert CLA 2019-05-07 06:01:48 EDT
I see you are using 4.9. Please try with https://download.eclipse.org/eclipse/downloads/drops4/S-4.12M1-201904110625/
Comment 3 Eclipse Genie CLA 2021-04-27 18:24:47 EDT
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.
Comment 4 Stephan Herrmann CLA 2021-05-22 17:06:30 EDT
With this I'm able to reproduce:

//---
import java.util.function.Consumer;

public class BugTest
{
	public void test(int i)
	{
		this.someMethod(O -> {
			switch(i)
			{
				// pos2
				case 1:
					// pos1
				break;
				// pos3
			}
		});
	}
	
	public void someMethod(Consumer<Object> consumer){ /* no-op */}
}
//---

(In reply to N247S - from comment #0)
> In the above case we should be able to use the autocomplete at the marked
> position [pos1], yet it does not yield any result. I only managed to get the
> user-templates working.

acknowledged.

> - At pos2 and pos3 the autocomplete is working correctly.

Not for me. 

If I remove the lambda (so the switch becomes a statement of test(int)), then completions are given:
- pos1: various options: good
- pos2: only 'case' and 'default': good
- pos3: same as pos1, but really? Whatever I chose, it's dead code ...
Comment 5 Stephan Herrmann CLA 2021-05-22 17:08:55 EDT
@Gayan, do you want to take a look at this bug?
Comment 6 Eclipse Genie CLA 2023-05-26 15:26:24 EDT
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.