missing parentheses in function type definition

[TheAngryByrd]

Discussed in #1337

^{Originally posted by joprice January 8, 2025}
I'm asking this here as I'm not sure where to open an issue and the issue templates are quite hefty. Other issues I've opened were premature and maybe a distraction to contributors, since they may have been issues in the underlying fsharp compiler libraries powering fsautocomplete. (It's also tricky to search for an existing issue across many repos, as this may be fixed already on head).

I've found that the type hint shown for certain types where a type is parameterized by a tuple and a function are not correctly printed with the correct precedence. For example, In the screenshot below, it shows a tupled function to 'c instead of a tuple of a value and a function from unit to `c.

This affects the Add explicit type annotation code action, which is where I usually notice it, since the provided type causes a compilation error in otherwise working unannotated code.

(In passing, another issue with the Add explicit type annotation I noticed is that it doesn't add the requires bounds, so the type ends up being just `c in this specific case when it's used on an untyped token, which is valid, but perhaps surprising given that the tooling shows a more specific type.)

[TheAngryByrd]

Have to investigate where the problem is coming from. Probably best to start TextDocumentHover endpoint and see where it leads.

[github-actions]

🤖 This is an automated response from Repo Assist.

I traced this through the codebase. There are two code paths that produce type annotation strings:

1. Inlay hints (src/FsAutoComplete.Core/InlayHints.fs, MissingExplicitType.FormatType):

let typeName = ty.Format displayContext

This calls FCS's Format() directly — so if inlay hints show a wrong type, the root cause is in how FCS formats the type.

2. "Add explicit type annotation" code fix (src/FsAutoComplete/CodeFixes/AddExplicitTypeAnnotation.fs, lines 90–117):
This manually decomposes function types via GenericArguments and reconstructs the annotation string by joining segments with ->. It wraps segments in parens only when t.IsFunctionType is true:

|> List.map (fun t ->
    let formattedType = t.Format(symbolUse.DisplayContext)
    if t.IsFunctionType then $"({formattedType})"
    else formattedType)
|> String.concat " -> "

A tuple type like int * (unit -> 'c) is not a function type at the top level, so it won't get wrapped. If FCS formats the inner function type without parentheses (returning int * unit -> 'c instead of int * (unit -> 'c)), the reconstructed annotation becomes ambiguous.

Possible FSAC-side workaround for path #2: after getting formattedType for a non-IsFunctionType segment, check whether the string contains -> — if so, wrap in parentheses to preserve the tuple-vs-function precedence. Something like:

|> List.map (fun t ->
    let formattedType = t.Format(symbolUse.DisplayContext)
    if t.IsFunctionType || (not t.IsFunctionType && formattedType.Contains(" -> ")) then
        $"({formattedType})"
    else
        formattedType)

It would be worth confirming whether FCS's Format() is the source of the wrong output (by checking the raw string returned for the tuple type), as that would tell us whether path #1 (inlay hints) also needs a fix, or only path #2 (the code action).

Generated by Repo Assist

To install this workflow, run gh aw add githubnext/agentics/workflows/repo-assist.md@ee50a3b7d1d3eb4a8c409ac9409fd61c9a66b0f5. View source at https://github.com/githubnext/agentics/tree/ee50a3b7d1d3eb4a8c409ac9409fd61c9a66b0f5/workflows/repo-assist.md.