Tracking: F# Hints

[psfinaki]

Note
This is a "meta" issue for tracking purposes since GitHub does not support special types of issues.

Supersedes #10289.

We'll be introducing a feature called F# hints. It is inspired by C# inline hints but will do more! The feature is going to be built on top of the dedicated Roslyn API.

This will supersede the experimental CodeLens feature that is current present in Visual Studio. The CodeLens brand in F# is planned to do the same as in other languages, i.e. show references, test coverage and so on (details here).

The plan is to gradually add different hints and make them configurable. Here is the proposed roadmap:

• Implement inline type hints for F# #14158 (experimental)
• Implement parameter name inline hints for F# #14174 (experimental)
• Remove CodeLens in its current form: Remove F# Lens #14256
• Add parameter name hints for methods #14259
• Don't show parameter name hints when they coincide with argument names #14447
• Move out of the experimental mode to the preview mode
• Consider showing inline hints to the right side of the cursor #14385
• Don't show parameter name hints for some built-in types #14448
• Make Type Hints less intrusive #14382
• Add type hints for the return type of function or member #14379
• Implement click-to-show behavior for the hints #14260
• Add tooltips for the hints #14268
• Don't show hint for a field name when it coincides with the variable name #15157
• Move out of the preview mode
• Implement granular control for F# hints #15131
• Implement signature hints
• Implement pipeline hints

Bugs:

• Type hints break for some tuple cases #14269
• Type Hints showing unsolved type in for expression #14393
• Type hints show redundant info in SRTP #14400
• Inline parameter name hints work weirdly with indexes #14401
• Wrong type hint for a module value containing a lambda #14378
• Incorrect and superfluous parameter hints in methods with optional parameters #14459
• Incorrect hints for CustomOperations in a computation expression #14460
• Hints throw exception #14885
• Parameter name hints in VS get somewhat mangled with nested function calls #15138
• VS counts hints into line length #15576
• Inline parameter name hints work weirdly with slices #15994

[kerams]

Can hints themselves have tooltips? This here looks like an empty one:

It would be nice to reuse type annotation tooltips with all the good stuff like clickable references:

(Sorry if this is not the place for a Hints discussion)

Looks like a function needs to be passed in
https://github.com/dotnet/roslyn/blob/315c2e149ba7889b0937d872274c33fcbfe9af5f/src/Tools/ExternalAccess/FSharp/InlineHints/FSharpInlineHint.cs

Also I've noticed that GetInlineHintsAsync is invoked twice after one keystroke. Is it a Roslyn thing?

[vzarytovskii]

I think it's a great idea, we should make hints interactive if we can.

[psfinaki]

Sorry if this is not the place for a Hints discussion

This IS a place for hints discussion :)

Can hints themselves have tooltips?

I think so. As long the information doesn't aggressively jump on the user, it's only helpful.

Also I've noticed that GetInlineHintsAsync is invoked twice after one keystroke. Is it a Roslyn thing?

On the one hand, it sounds suspicious, on the other hand, I don't have an idea what in our code can trigger this, we have a very thin layer now. I will investigate.

[majocha]

This is probably bug on Roslyn side, but hints won't go away when you release Alt+F1, unlike in C# editor.

[vzarytovskii]

This is probably bug on Roslyn side, but hints won't go away when you release Alt+F1, unlike in C# editor.

No, it's not implemented yet. Tracked in #14260

[raymens]

It would be nice if a Numerics.BigInteger would be shown as bigint instead.
Not sure if there are any other similar types.
Is there already some sort of mapper to simplify names? In that case I could maybe have a go at it.

[psfinaki]

@raymens so, that's an interesting thing and it also applies to the tooltips. You get the full type name there unless you have specified in the opens. Take a look:

fulltypes.mp4

This somewhat makes sense to me. Also this means that probably in many cases you'd have the short types there. WDYT?

---

That said, the tooltips for the hints themselves show the short type anyway:

This is inconsistent and worth fixing.

---

Now, as for the mechanics of that, I think this is not a big deal and basically just depends on what info you take from the symbol:

[kerams]

I think his point is that BigInteger should behave like Int32 does, where we don't use the .NET name but the F# one.

According to https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/basic-types, bigint is an abbreviation, but the type itself does not count as a basic F# type.

[psfinaki]

Oh, that thing. Well so the docs above pretty much answers the question :)

I am on a fence then. We can technically hardcode this conversion in the code but, given that this seems to be the only thing of that nature - and it's not very common I guess - not sure if it's worth it.

[raymens]

Thanks for the detailed explanation.
I was indeed mostly referring to the (to us highly used) bigint abbreviation.

Maybe the solution is to consider bigint a basic type instead... considering it's the only one apparently. However I'm going off-topic and there's probably reasons why that's the case.

[psfinaki]

Well, that's because it's arguably not that basic :)

I think, yeah, just mapping this type to its short form would be sufficient. I would be up for having it. Feel free to jump on this, or we can create a ticket and someone will eventually pick it up.