Add chain completions support

[gayanper]

Bring chain completions support to JDT.LS which was started by @rgrunber. I clean it up a little bit and add

• Support for overloaded methods where expected type signatures in the context is more than one.
• Some support suggesting chain completions using static methods in classes like Collectors as a POC. The idea is to improve the this to read from a simple model file where either Microsoft IntelliCore (cc: @jdneo @testforstephen) can provide or any other interested extension provider. We need to discuss the best way to provide this as a extension point for providing model information (cc: @rgrunber @mickaelistria @fbricon )

[gayanper]

Related vscode extension PR redhat-developer/vscode-java#3008

[gayanper]

@rgrunber will you have time to look into this change ?

[gayanper]

@rgrunber let me know how it looks now, so if things look good, I can see to add some tests.

[rgrunber]

I think the postfix completion tests and chain ones were done in the exact same way in JDT-UI. So I would have a look at https://github.com/eclipse-jdt/eclipse.jdt.ui/blob/master/org.eclipse.jdt.text.tests/src/org/eclipse/jdt/text/tests/contentassist/ChainCompletionTest.java for test ideas and https://github.com/eclipse/eclipse.jdt.ls/blob/master/org.eclipse.jdt.ls.tests/src/org/eclipse/jdt/ls/core/internal/handlers/PostfixCompletionTest.java for how the utility methods were written that do the actual testing.

Hope to find some time to have another look at this.

[gayanper]

I think the postfix completion tests and chain ones were done in the exact same way in JDT-UI. So I would have a look at https://github.com/eclipse-jdt/eclipse.jdt.ui/blob/master/org.eclipse.jdt.text.tests/src/org/eclipse/jdt/text/tests/contentassist/ChainCompletionTest.java for test ideas and https://github.com/eclipse/eclipse.jdt.ls/blob/master/org.eclipse.jdt.ls.tests/src/org/eclipse/jdt/ls/core/internal/handlers/PostfixCompletionTest.java for how the utility methods were written that do the actual testing.

Hope to find some time to have another look at this.

I added one test, But i can also include the similar scenarios in JDT UI Chain Completion, if you think the approach of this implementation is good to be included in JDT.LS.

I have done a additional thing to discover the context specific entry points to find completions at computeContextEntrypoint, I think we could later introduce a SPI or commandHandler extension for this too.

@rgrunber Let me know what you think so we can finish this soon.

[rgrunber]

It works well for me, and as long as we disable by default, I think it should be fine to merge. only other thing I noticed is that since we started using the labelDetails field of completion items, the items are displayed a bit differently now :

We could always address this in a subsequent change though.

[gayanper]

It works well for me, and as long as we disable by default, I think it should be fine to merge. only other thing I noticed is that since we started using the labelDetails field of completion items, the items are displayed a bit differently now :

We could always address this in a subsequent change though.

Check the latest chains @rgrunber I also tried to make the label details closer to other completion items.

[gayanper]

@rgrunber when will you be able toe check the latest changes ?

[rgrunber]

I think it's just a matter of getting rid of duplicates, and cleaning up how the return value is displayed (unnecessary .)

I'm not sure why there are duplicates though. The example above comes from a testcase in JDT where we assert only 1 element is discovered (from the chain completion proposal computer).

Update: I think there are duplicates added to entrypoints in findEntrypoints(..).

[gayanper]

@rgrunber

I think it's just a matter of getting rid of duplicates, and cleaning up how the return value is displayed (unnecessary .)
Fixed

Update: I think there are duplicates added to entrypoints in findEntrypoints(..).
Fixed

[rgrunber]

Change works well so I'm going to merge. In addition it's disabled so at least it if there's anything we missed, it won't be a problem by deafult.

Just one thing I noticed. I took a project like https://github.com/eclipse/lemminx/blob/main/org.eclipse.lemminx/src/main/java/org/eclipse/lemminx/XMLLanguageServer.java#L129C5-L129C73 and wanted to show that the suggestion would be made for something like ExtendedClientCapabilities cap = |, but i couldn't see the suggestion until I increased the chain completion timeout setting.

I think in the future we should look at how we prioritize the entry points, perhaps choosing local variables before static types.

[gayanper]

I can improve it @rgrunber. Will push a new PR during next few days or next week.