TypeApp, type parameter completions

[kerams]

The first part of this PR deals with completions inside of a type application (SynExpr.TypeApp). Given

let arr = Array.empty<str>

pressing Ctrl-space on str will now only show type-like completions. Currently the list also contains keywords and functions.

Secondly, type variables (parameters) in scope are now included in the list of completions. Given

let emptyMap<'keyType, 'valueType> () =
    Map.empty<'keyType, va>

type Option<'typ> =
    | None
    | Some of ty

pressing Ctrl-space on va or ty will show type-like completions, including valueType and typ, respectively. ' (or ^ for SRTPs) is added automatically when the completion is used. (I have a vague memory this was thing in the past, and that you'd often end up with 2 apostrophes. Maybe in Power Tools pre-Roslyn?)

Thirdly, type variables now have (currently not really useful) tooltips and are clickable (F12 navigation works already).

Thoughts/open issues (for future PRs?)

1. In C# tooltips for type parameters show where the latter is declared.
   
   Typar doesn't seem to directly contain such information. Is there a way I can quickly find out the record/union/type definition or method/function as the point of declaration?

2. Because denv.showConstraintTyparAnnotations is false, SRTP tooltips show up with an apostrophe instead of a caret, which looks a bit weird.
   

3. I would like to see only type-like completions pop up in all of these cases

   let abc<'typ> = Array.empty<
   let abc<'typ> = Array.empty<'
   let abc<'typ> = Array.empty<'>
   let abc<'typ> = Array.empty<>
   let abc<'typ> = Array.empty<'t

   The parser detects an error and reports SynExpr.App, and the presence of a less than/inequality operator, so the TypeApp completion context cannot be immediately established. Unfortunately, because of type inference, we cannot really rule out the possiblity that the user wants to make a comparison, however unlikely it would be in these 5 functions.

4. When type variables are in scope, I feel they should have a high priority on the completion list, because are likely to be used. When func<' > is typed, they should certainly be the only items on the list.

5. typeparam XmlDoc does not appear to be collected on a function. We could at least show that in the tooltip.

[kerams]

In light of points 3 and 4, I'd rather remove CompletionContext.TypeApp and abuse CompletionContext.PatternType. The reason is that we might like to have the TypeApp case carry further information in the future, and we'd be making a breaking change then.

[kerams]

I'm not really sure ResolvePartialLongIdentPrim is the place to insert these type variables as it's outside of the FCS.

[baronfel]

Not sure exactly what you mean by 'outside of FCS' here. This seems like a reasonable change, and sometimes lower level changes need to be made in order to surface better behaviors in the user-facing APIs.

[kerams]

Well, it's outside of the service folder, so I thought this file was part of the compiler proper.

[kerams]

Let me know how you want to proceed. If the PR is acceptable as it is, I'll just update the surface area.

[vzarytovskii]

Let me know how you want to proceed. If the PR is acceptable as it is, I'll just update the surface area.

Is it possible to add some tests for type-parameters completions? Just couple of simple ones?

Overall, I think, this is great, @KevinRansom @cartermp thoughs?

[kerams]

Good idea, that slipped my mind.

[kerams]

Two more points.

nenv.eTypars is empty when collecting completions in type A<'lType> = { Field: l }. This is in contrast with type A<'lType> = Case of l, where 'lType is present in the dictionary.

For let blah<'foo1> (x: 'foo2) = Unchecked.defaultof<foo> nenv.eTypars contains only 'foo1.

[vzarytovskii]

Thanks!