Wrong IDE0055 in combination with CRLF, XML comment and preprocessor directive

[mus65]

Version Used:

.NET SDK 8.0.204

Steps to Reproduce:

The following code will report IDE0055 on line 2, but only if the file has CRLF line endings:

namespace Ide0055Bug
{
    /// <summary>
    /// test.
    /// </summary>
#pragma warning disable TEST
    [Serializable]
#pragma warning restore TEST
    public class Class1
    {

    }
}

The warning disappears if you either:

• change the file to LF
• remove the XML comment
• remove the pragma directive

I created a repo with a reproduction: https://github.com/mus65/Ide0055Bug

dotnet build reports:

Ide0055Bug/Class1.cs(2,2): error IDE0055: Fix formatting (https://learn.microsoft.com/dotnet/fundamentals/code-analysis/style-rules/ide0055)

dotnet format Ide0055Bug.csproj whitespace --verify-no-changes reports:

Ide0055Bug/Class1.cs(2,2): error WHITESPACE: Fix whitespace formatting. Replace 6 characters with '\n\s\s\s\s'. [Ide0055Bug/Ide0055Bug.csproj]
Ide0055Bug/Class1.cs(7,1): error WHITESPACE: Fix whitespace formatting. Replace 4 characters with '\s\s\s\s'. [Ide0055Bug/Ide0055Bug.csproj]

this was noticed in sshnet/SSH.NET#1380

Diagnostic Id:

IDE0055

Expected Behavior:

no IDE0055 warning.

Actual Behavior:

IDE0055 warning.

[sharwell]

I am not able to reproduce this locally. I suspect this bug is reproducible due to the following:

1. The author is running on an operating system which treats \n as the default line ending (non-Windows)
2. The sample repository specifies eol=crlf in .gitattributes (this defines the form of files on disk), but fails to set the matching end_of_line option in .editorconfig (this defines the expected form of files in the build).

Warning

I do not recommend explicitly setting eol or end_of_line options, as described in #71659 and issues linked to it.

Note that this setup is different from the situation that led to this bug getting filed in the first place. The original issue appeared on a Windows CI system as part of sshnet/SSH.NET#1380. I left comments on that issue regarding the suspected root cause of those problems.

[mus65]

@sharwell sorry, you are right, my repro only works on linux. I just tested it on windows and also can't reproduce it there.

[EdwardCooke]

I have this same thing in YamlDotNet. It also manifests itself when you have comments in inline if statements like this:

https://github.com/aaubry/YamlDotNet/pull/978/files#diff-23cf9e47bbe27bf8bbb2f21efa59ed56aba2b64ae298efdb35a26ddc3e5d583f

Not sure if that inline if issue is related to the same bug, but it only appears in Linux and enforcing CRLF (not sure on enforcing line feeds), which we needed to do because of all of the line ending inconsistencies from people developing on both Linux and Windows and/or developer preference settings, maybe even some editors that didn't respect editorconfig, which led to inconsistent line endings which at a minimum caused a lot of popups in Visual Studio when opening files with inconsistent line endings.

[sharwell]

@EdwardCooke that project unexpectedly sets the line ending for .cs files:

https://github.com/aaubry/YamlDotNet/blob/485daaa7fa2a9fdc5863294ef580b880aac6a4df/.gitattributes#L2

The line file contents should be:

* text=auto
*.sh text=auto eol=lf

[EdwardCooke]

@sharwell thanks, I'll make that change and see what happens. What we found in the past is that if someone committed a change with LF line endings in the middle of the file, git checked in those line endings even though the rest of the file was CRLF. Which resulted in the inconsistent line endings.