Bug 533524 - [call hierarchy] call hierarchy should show lambdas
Summary: [call hierarchy] call hierarchy should show lambdas
Status: RESOLVED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.8   Edit
Hardware: All All
: P3 enhancement with 8 votes (vote)
Target Milestone: 4.22 M2   Edit
Assignee: Zsombor G CLA
QA Contact:
URL:
Whiteboard:
Keywords: noteworthy
: 468561 575985 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-04-12 16:25 EDT by Sam Davis CLA
Modified: 2022-04-13 12:03 EDT (History)
10 users (show)

See Also:


Attachments
Slightly modified patch shows [declaration] matches for lambdas (115.99 KB, image/png)
2021-10-11 06:03 EDT, Andrey Loskutov CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sam Davis CLA 2018-04-12 16:25:56 EDT
Similar to how the call hierarchy shows a constructor invocations node for anonymous classes, it should show the callers of the method in which a lambda appears. Since lambdas are basically just syntactic sugar for anonymous classes I expected this would work. Not having this makes the call hierarchy much less useful for Java 8 code.
Comment 1 Stephan Herrmann CLA 2018-04-12 17:03:56 EDT
One issue is: how do we name that node? In the other bug I mentioned constructor invocations (for anonymous) as an analogy, but obviously, a lambda has no constructor.

If a lambda is defined within a method, then s.t. like "declaring method" could perhaps be used. Lambdas in (field,instance,static) initializers have no interesting incoming flow in this regard, do they?

As a downside, all lambda expressions would have two intermediate nodes with little information added:
  () -> {}
    + [declaring method] foo()
    + [callers]

Just saying.
Comment 2 Sam Davis CLA 2018-04-12 20:28:01 EDT
I contend that in at least 90% of cases the user is only interested in the [declaring method] node and not the callers of the lambda. Lambda's are normally used for interfaces like Function which have thousands of implementations and are used all over the place, so seeing the list of all callers is not useful at all.

> If a lambda is defined within a method, then s.t. like "declaring method" could
> perhaps be used. Lambdas in (field,instance,static) initializers have no
> interesting incoming flow in this regard, do they?

That's right. It would very useful if the call hierarchy could show relationships other than just method calls, e.g. if a lambda (or just a method call) is used in an instance or field initializer, it could show calls to the declaring class's constructor, but that is out of scope of this bug.
Comment 3 Andrey Loskutov CLA 2021-09-20 08:45:02 EDT
*** Bug 575985 has been marked as a duplicate of this bug. ***
Comment 4 Andrey Loskutov CLA 2021-10-11 06:03:37 EDT
Created attachment 287293 [details]
Slightly modified patch shows [declaration] matches for lambdas

Screenshot for slightly changed patch: https://git.eclipse.org/r/c/jdt/eclipse.jdt.ui/+/185428

Instead of "[declaring method]" use [declaration], to avoid confusion on fields etc? WDYT?

Beside this, I found this patch very useful, I would like to merge that ASAP :-).
Comment 5 Andrey Loskutov CLA 2021-10-11 06:04:29 EDT
(In reply to Andrey Loskutov from comment #4)
> Created attachment 287293 [details]

Here is the corresponding snippet to try:

import java.util.List;
import java.util.function.Function;

public class Snippet {
	static Function<? super String, ? extends String> mapper1 = y -> transform(y);
	Function<? super String, ? extends String> mapper2 = y -> transform(y);

	static {
		 mapper1 = y -> transform(y);
	}

	public Snippet() {
		mapper2 = y -> transform(y);
	}

	public static void main(String[] args) {
		mapper1 = y -> transform(y);
	}

	Object[] funcCall() {
		return List.of("aaa").stream().map(y -> transform(y)).toArray();
	}

	static String transform(String s) {
		return s.toUpperCase();
	}
}
Comment 6 Andrey Loskutov CLA 2021-10-14 03:07:50 EDT
Anyone has any objections for merge? With no feedback here or on the patch I plan to merge proposed patch today evening CET.
Comment 7 Noopur Gupta CLA 2021-10-14 06:48:56 EDT
Thanks, Zsombor and Andrey for the patch. Looks good and can be merged for further feedback.
Comment 9 Andrey Loskutov CLA 2021-10-15 02:12:52 EDT
Build I20211014-1800 contains the patch, I've verified it works as proposed.
Please test & provide feedback, ideally before next week M2.

See https://download.eclipse.org/eclipse/downloads/drops4/I20211014-1800/

@Zsombor: would you please prepare N&N entry?

Repo is https://git.eclipse.org/r/www.eclipse.org/eclipse/news.git
Comment 10 Andrey Loskutov CLA 2021-10-18 12:19:27 EDT
(In reply to Andrey Loskutov from comment #9)
> @Zsombor: would you please prepare N&N entry?

ping.
Comment 11 Zsombor G CLA 2021-10-18 16:53:55 EDT
I hope, this makes sense: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/186625/1
Comment 13 Andrey Loskutov CLA 2021-10-20 10:18:41 EDT
(In reply to Zsombor from comment #11)
> I hope, this makes sense:
> https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/186625/1

Yes, it does :-) Many thanks!
Comment 14 Andrey Loskutov CLA 2022-04-13 12:03:37 EDT
*** Bug 468561 has been marked as a duplicate of this bug. ***