Support postfix completion

[jdneo]

• Reuse the headless part of code from jdt.ui.
• The supported templates in this PR are: cast, else, for, fori, forr, if, nnull, null, sysout, throw, var, while.

fix redhat-developer/vscode-java#1455
fix #863

requires redhat-developer/vscode-java#2746

How to test

Performance analysis

We will only calculate the postfix completions when:

• The completion is triggered by the trigger character .
• The completion is triggered manually

In most cases, it just skips the postfix completion calculation.

Below is the CPU sampling when we trigger the completion for the code args.|, where args is a String[]:

Though it takes 36% of the CPU times, the time for completion after . is relatively fast, so the real response time is still very quick.

Overall, the impact of the completion performance is acceptable.

Known issues

• The postfix snippets always list at the top, no matter how I set the sortText. This seems a bug of VS Code, I've filed an issue.
• The implementation relies on the AST, which means, if the file contains some compilation errors, some of the postfix snippets will be unavailable. Same behavior can be observed in Eclipse as well.

Next step

1. Support more postfix templates, like the ones which will generate multiple text edits. See: Provide postfix completion #863 (comment). (Full list of the post fix templates can be found here)
2. Revisit Add contribution points for completion customization #2110, each time when we modify the completion part, same changes need to apply to the intellicode extension. I hope to decouple them.

Signed-off-by: Sheng Chen [email protected]

[jdneo]

@gayanper In case you are interested in this.

[jdneo]

TODO:

1. Add a preference to switch the feature, and turn it off if we cannot find a way to put the postfix at the bottom of the list.
2. Check if it's necessary to resolve the binding when parsing the AST

[mfussenegger]

The postfix snippets always list at the top, no matter how I set the sortText. This seems a bug of VS Code, I've filed microsoft/vscode#163923.

I just tried this PR and I can observe the same in Neovim with a sort implementation according to spec (it sorts by sortText if present, and if missing by label)

[jdneo]

Add a preference to switch the feature, and turn it off if we cannot find a way to put the postfix at the bottom of the list.

So far, I haven't figured out a way to avoid the strange ranking behavior, changing completion kind or insert text format do not help neither.

Check if it's necessary to resolve the binding when parsing the AST

Resolve binding is required since we need to know the type information for some template like .var.

[jdneo]

test this please

[jdneo]

This PR is mainly focusing on migrating the current postfix implementation from Eclipse to JDT.LS and make it work in most basic cases. Meanwhile, there are some problems found during the implementation, most of them can also be found in Eclipse as well. I would like to address them in the different PRs to make the commit history much easier to tell the differences we made comparing with the Eclipse implementation. In the future, when we decide to move the headless version to JDT, it will make it clear.

The list of issues that I want to address:

1. Postfix should not be available after a type, e.g. System.|.
2. The ranking among the different postfixes. (Now it's alphabetical)
3. Additional textedit support. (detail)
4. Some of the postfix is not available when the file has compilation error.

[testforstephen]

Current version basically works for me, I'm OK to merge it first to keep the commit history clean. When you open the new PR to address the remaining issues, pls consider how to make the IntelliCode to adopt the postfix as well.

[testforstephen]

With the latest change, postfix works with or without IntelliCode extension. LGTM.

[rgrunber]

Check if it's necessary to resolve the binding when parsing the AST

Resolve binding is required since we need to know the type information for some template like .var.

Yup, for some reason JavaPostfixContext was hidden in the "File Changed" tab (due to size) which made me think maybe binding weren't needed at all, but yes, as you've discovered, we need them to evaluate which templates should be suggested.

[jdneo]

I'm merging this PR first, but still open to discuss whether the feature should be enabled by default or not.