Comment above single parameter in brackets breaks code due to wrong indentation

[stefan-schweiger]

Issue created from fantomas-online

Code

let doSomething _ _ = ()

let test1 param =
    doSomething
        // my comment
        (param)

let test2 param =
    doSomething
        // my comment
        (param)
        (param)

Result

let doSomething _ _ = ()

let test1 param =
    doSomething
    // my comment
    (param)

let test2 param =
    doSomething
        // my comment
        (param)
        (param)

Problem description

If there is a comment above a single parameter which is in brackets the resulting code has the wrong indentation and breaks. It works fine if multiple parameters are supplied.

I know the sample is pretty simple and you could just remove the brackets. But the same thing happens for parameters which are functions with applied parameters.

Extra information

• The formatted result breaks my code.
• The formatted result gives compiler warnings.
• I or my company would be willing to help fix this.

Options

Fantomas main branch at 2022-10-19T15:02:12Z - 25cb8d5

Default Fantomas configuration

_{Did you know that you can ignore files when formatting from fantomas-tool or the FAKE targets by using a .fantomasignore file?}

[nojaf]

Hello, some context on this one:
When a tupled function invocation is multiline, it will write something like fn (a,b,c) to

fn (
    a,
    b,
    c
)

(style guide)
The code comment between fn and ( makes the code follow the multiline path.
When Fantomas changes the indentation, it only kicks in when the next newline is added.

So what happens here is:

doSomething
// my comment
(

the indentation will kick in on the following line, but as (param) is too short it will never get to that point.
(Example where it does kick in).

If the parentheses have trivia, we probably want to indent right before the opening parenthesis.
One could of course argue if there needs to be any indentation at all (I mean between the parentheses and the argument expr), but that would be a matter to discuss in the F# style guide.

[nojaf]

Fix available in v5.2.0-beta-001