Improve signature help when completing object argument

[mjbvz]

From https://github.com/Microsoft/vscode/issues/56270

TypeScript Version: 3.3.0-dev.20181214

Search Terms:

Code For a simple TS File:

function foo(x: number, i: { ab: number, cd: number }) { }

foo(1, {

Trigger signature help on last line.

Problem: We currently just display the entire type in signature help:

Some possible quality of life improvements:

• Underline which parameter you are currently typing and show its documentation
• Show which parameters have already been completed vs which ones are missing

This is likely not supported by the current VS Code api. Opening this issue for further discussion on how this could be improved

/cc @DanielRosenwasser

[DanielRosenwasser]

I spoke with Mohamed a lot about this. The problem is that there's really no "current" parameter in an options bag until you've typed out the whole word, or inserted a colon. At that point, we could possibly display something like

{ ..., currentPropertyName: string, ... }

[DanielRosenwasser]

Trying to give some context on this one:

---

Today in TypeScript, signature help really only thinks about a set of overloads, each having a flat argument list. There is some special functionality to make rest arguments of union types turn into several overloads, but that still boils down to a list of signatures with a flat set of arguments.

However, it's very common to think about option bags in JS/TS. These option bags often act as a set of named parameters, and one could imagine signature help specially "drilling down" to give a better experience, updating the display on retriggers, and giving more information for nicer formatting. This might include:

1. Re-writing the surrounding parameters to take up less space. Maybe their types can be omitted, maybe they can be replaced with ...s entirely. Maybe that's something the editor side could do depending on the current index given enough information.
2. Re-writing the current parameter based on the type that it's clearly going to be. For example, if you have an object literal, you should not try to show that the current parameter can possibly be an array or whatever. This is similar to what we do for error elaboration, and it would happen purely on TSServer. This includes
   1. Removing irrelevant types.
   2. Possibly replacing type references with an anonymous object type. For example, replacing a type named FooOptions with an object literal type (while properly handling recursive types).
3. "Drilling down" to give signature on individual properties, giving the illusion of named parameters, similar to what we do for Python.
4. Giving back appropriate display parts so that the editor can format parameters a bit more nicely. (e.g. splitting into multiple lines and the like)