Incorrect line split when using a custom operator

[chausner]

Issue created from fantomas-online

Code

let inline (%%) x y = ((x % y) + y) % y

let aVeryLongVariableName = 0

let a = (if aVeryLongVariableName = 0 then 1 else -1) %% 4

Result

let inline (%%) x y = ((x % y) + y) % y

let aVeryLongVariableName = 0

let a =
    (if aVeryLongVariableName = 0 then
         1
     else
         -1)

    %% 4

Problem description

Fantomas incorrectly moves the custom %% operator to a new line which makes the code not compile anymore.

Extra information

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

Options

Fantomas master branch at 1/1/1990

Default Fantomas configuration

[nojaf]

Hello @chausner, thank you for reporting this problem.

This one is interesting on a couple of levels:

• There is an idempotency bug/newline bug
• The AST changed from an infix operation to a sequential
• The result is valid again adding an additional space:

let a =
    (if aVeryLongVariableName = 0 then
         1
     else
         -1)
      %% 4

Other operators don't seem to have this problem, I wonder why.

I'm not sure how to tackle this one, to be honest.
You could increase fsharp_max_if_then_else_short_width to work around the problem.
Sample

[chausner]

You could increase fsharp_max_if_then_else_short_width to work around the problem.

Yes, that should work as a workaround in this case but the problem does not seem to be related to if..then..else as it also occurs in this somewhat contrived example:

let inline (%%) x y = ((x % y) + y) % y

let a = 5 %% 5 %% 5 %% 5 %% 5 %% 5 %% 5 %% 5 %% 5 %% 5 %% 5 %% 5 %% 5 %% 5

which gets formatted to

let inline (%%) x y = ((x % y) + y) % y

let a =
    5
    %% 5
    %% 5
    %% 5
    %% 5
    %% 5
    %% 5
    %% 5
    %% 5
    %% 5
    %% 5
    %% 5
    %% 5
    %% 5

Other operators don't seem to have this problem, I wonder why.

I see the same issue with the modulo operator. The following is not accepted by the F# compiler:

let b =
    5
    % 5

But replacing the operator with +, it is valid. So it seems there are certain operators which may be put onto a separate line and others may not.

[chausner]

So it seems there are certain operators which may be put onto a separate line and others may not.

I investigated this a bit further and found that from the following operators:

+ - * / % %% ** < <= > >= <> = && || &&& <<< >>> ^^^ ||| ~~~

only these operators are not accepted on a new line:

% %% < > =

For % and %%, the compiler (incorrectly?) recognizes the operators as (~%) and (~%%), defined in https://fsharp.github.io/fsharp-core-docs/reference/fsharp-core-extratopleveloperators.html.

For <, > and =, the compiler fails with a more generic FS0010 error.

I wonder if this behavior is by design or a compiler bug. I created dotnet/fsharp#12754 to clarify.

[nojaf]

Thank you for following up on this.

[github-actions]

🤖 This is an automated response from Repo Assist.

I investigated this issue and confirmed it is reproducible in the current main branch when the infix expression is long enough to require line-breaking.

Root cause: CodePrinter.fs maintains a noBreakInfixOps set of operators that must stay on the same line as their LHS (because they can be parsed as unary prefix operators when they appear at the start of a new line). The set contains %, =, <, > — but was missing %%.

When the expression became too long, Fantomas used genMultilineInfixExpr which always places the operator at the start of the next line:

let a =
    (if aVeryLongVariableNameThatForceLineBreaking = 0 then
         1
     else
         -1)
    %% 4   // ← invalid: F# parser reads %% at start of line as unary splice operator

The F# compiler then rejects this with error FS0001: This expression was expected to have type 'Quotations.Expr' but here has type 'int' — because %% at the start of a line is the quotation untyped splice operator (~%%).

Fix: Adding "%%" to noBreakInfixOps keeps the operator on the same line as the LHS (matching the existing behaviour for %). I've submitted a draft PR with this fix and a regression test.

As a workaround in the meantime, you can set fsharp_max_infix_operator_expression to a higher value to prevent the expression from being broken across lines.

Generated by Repo Assist · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@346204513ecfa08b81566450d7d599556807389f