format icon indicating copy to clipboard operation
format copied to clipboard

dotnet format doesn't like comments within statements broken across multiple lines

Open gregsdennis opened this issue 3 years ago • 6 comments
trafficstars

It appears that dotnet format --verify-no-changes will result in a non-zero exit code for comments that are positioned within a single statement.

SomeMethodCall(
    param1,
    // this will be reported as a formatting error
    param2 // this is reported, too
);

The error message will be something like

error WHITESPACE: Fix whitespace formatting. Replace 14 characters with '\n\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s\s'.

but adjusting indentation doesn't fix the problem; only moving the comment out of the method call fixes it.

Additionally, just running dotnet format doesn't fix this. The only fix I think would be appropriate given the error would be to move the comment above the method call.

Interestingly, there is no problem with comments between statements inside lambda expressions that are themselves inside method calls.

SomeMethodCall(
    param1,
    () => {
        Console.WriteLine("content");
        // this is okay
        Console.WriteLine("more content");
    },
    param2);

Expected Behavior

Comments in these locations should be allowed. I'm not sure if there's a way to specify this in an .editorconfig file, though.

Alternatively, I would expect that formatting that is not fixed by dotnet format should not be reported by dotnet format --verify-no-changes.

gregsdennis avatar Mar 30 '22 22:03 gregsdennis

We are also running into this, though I am experiencing the additional odd behavior that this only repros in our CI and not locally, so there may be differences in behavior here based on line endings.

Update, it seems like this may only show up if the end_of_line setting in your .editorconfig does not match your .gitattributes (and/or autocrlf) settings. It is interesting that this only shows up on comments within multiline statements and not anywhere else.

jackhorton avatar Apr 13 '22 16:04 jackhorton

I can reproduce this locally. On Windows, I have files that use CR LF line ending. Then I have a docker file that includes step to RUN dotnet format --verify-no-changes. The dockerfile specifies FROM mcr.microsoft.com/dotnet/sdk:6.0, so it's a Linux environment.

Running docker build fails with error WHITESPACE: Fix whitespace formatting. Replace 4 characters with '\s\s\s\s'.

However, my overall CI Linux build works because I think that checks out files with line endings as just LF.

Running dotnet format directly in Windows is also fine. It's just the weird hybrid case of local docker build copying CR LF files into the Linux container image that seems to break.

andrewdavey avatar Jun 21 '22 19:06 andrewdavey

did this error can be deleted when using dotnet format --verify-no-changes in some way? I run the cmd in pipeline and meet the same error, even I didn't add any rules in .editorconfig.

kokolerk avatar Aug 03 '22 08:08 kokolerk

Same issue in our azure devops build pipeline (linux agent) and also in local dev environment (windows machines). --verify-no-changes does not change the result.

BernhardMaier avatar Sep 22 '22 10:09 BernhardMaier

We experienced a similar issue when setting <EnforceCodeStyleInBuild/> to true.

We got errors on comments within statements until we set the end_of_line = crlf in our .editorconfig. Then local builds (on Windows PCs and in Docker on Windows PCs) passed, but builds in the Azure DevOps pipelines continued to fail on all but our single Windows agent.

We tracked this down to Linux agents checking out our code with LF line endings instead of CRLF. By setting * text=auto eol=crlf in a .gitattributes file, we managed to make builds pass on Linux agents as-well (ref this random blog post https://www.aleksandrhovhannisyan.com/blog/crlf-vs-lf-normalizing-line-endings-in-git/#summary-git-config-vs-gitattributes).

We got here mostly thanks to @jackhorton's comment update above that hinted on the line endings and GIT.

I hope this helps others pondering over this issue.

Hesehus-TOAL avatar Aug 15 '24 06:08 Hesehus-TOAL

I encountered this problem also and boiled it down to this repro. Clone that repo on Windows with git config --global core.autocrlf false and run dotnet format:

dotnet format --verify-no-changes Formatted.csproj
C:\repos\Formatted\Program.cs(5,37): error WHITESPACE: Fix whitespace formatting. Replace 13 characters with '\r\n\s\s\s\s\s\s\s\s\s\s\s\s'. [C:\repos\Formatted\Formatted.csproj]
C:\repos\Formatted\Program.cs(6,23): error WHITESPACE: Fix whitespace formatting. Replace 13 characters with '\r\n\s\s\s\s\s\s\s\s\s\s\s\s'. [C:\repos\Formatted\Formatted.csproj]

The file was checked out with LF line endings, but the formatter wants to end just two of the lines with CRLF.

jaraco avatar Mar 14 '25 19:03 jaraco